According to POSIX, basename("/path/") should return "path", not
"path/". Likewise, basename(NULL) and basename("abc") should both
return ".".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Junio Hamano pointed out that there is an implicit assumption in pretty
much all the code calling has_dos_drive_prefix(): it assumes that the
DOS drive prefix is always two bytes long.
While this assumption is pretty safe, we can still make the code more
readable and less error-prone by introducing a function that skips the
DOS drive prefix safely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To be precise: when the value of the environment variable is shorter than
its name, we have to move the remaining bytes *after* expanding the
environment variable: we would look for the wrong name otherwise.
When the value is longer than the name, we still need to move the bytes
out of the way first, to avoid overwriting them with the interpolated
text.
This fixes https://github.com/git-for-windows/git/issues/509
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When moving bytes (because the name and the value of the environment
variable to interpolate differ in length), we introduce a variable to
unclutter the code and make it more obvious what is happening.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
After we found the `@@` marker after the key to interpolate, we pretty
much only need the offset *after* the marker. So let's just advance it
instead of adding 2 in many places.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When a user is registered in a Windows domain, it is really easy to
obtain the email address. So let's do that.
Suggested by Lutz Roeder.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We do have the excellent GetUserInfoEx() function to obtain more
detailed information of the current user (if the user is part of a
Windows domain); Let's use it.
Suggested by Lutz Roeder.
To avoid the cost of loading Secur32.dll (even lazily, loading DLLs
takes a non-neglibile amount of time), we use the established technique
to load DLLs only when, and if, needed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, we have to emulate the fstat() call to fill out information
that takes extra effort to obtain, such as the file permissions/type.
If all we want is the file size, we can use the much cheaper
GetFileSizeEx() function (available since Windows XP).
Suggested by Philip Kelley.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Often we are mmap()ing read-only. In those cases, it is wasteful to map in
copy-on-write mode. Even worse: it can cause errors where we run out of
space in the page file.
So let's be extra careful to map files in read-only mode whenever
possible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is not really helpful when a `git fetch` fails with the message:
fatal: mmap failed: No error
In the particular instance encountered by a colleague of yours truly,
the Win32 error code was ERROR_COMMITMENT_LIMIT which means that the
page file is not big enough.
Let's make the message
fatal: mmap failed: File too large
instead, which is only marginally better, but which can be associated
with the appropriate work-around: setting `core.packedGitWindowSize` to
a relatively small value.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`$HOME/bin/` is quite convenient a place to put user-specific Git
helpers, such as credential or remote helpers.
When run in Git Bash, it is therefore already appended to the PATH;
Let's do the equivalent when run in Git CMD: when `git.exe` is
called, Git is told to look also for scripts and programs in
`$HOME/bin` (this does not modify Git CMD's `PATH`, of course).
This fixes https://github.com/git-for-windows/git/issues/429
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We no longer use any of MSVCRT's stat-functions, so there's no need to
stick to a CRT-compatible 'struct stat' either.
Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond-
precision file times.
Note: Due to performance issues when using git variants with different file
time resolutions, this patch does *not* yet enable nanosecond precision in
the Makefile (use 'make USE_NSEC=1').
Signed-off-by: Karsten Blees <blees@dcon.de>
fstat() is the only stat-related CRT function for which we don't have a
full replacement yet (and thus the only reason to stick with MSVCRT's
'struct stat' definition).
Fully implement fstat(), in preparation of implementing a POSIX 2013
compatible 'struct stat' with nanosecond-precision file times.
Signed-off-by: Karsten Blees <blees@dcon.de>
The quoting rules of `cmd.exe` are really, really quirky. In particular,
if there are more than two quotes, the entire set of rules changes. That
is the reason why
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i
works, but
CMD /C "C:\Program Files\Git\usr\bin\bash.exe" -l -i "test.sh"
fails with this error message:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
The recommended fix is to pass the /S option to `cmd.exe` and surround
the entire command-line by an extra set of quotes. And here lies the
rub: for that to work, we have to append an extra quote. At the end of
the command-line. *After* the last argument was appended, if any.
This commit supports that use case by introducing the option
"APPEND_QUOTE". The intended usage is to use the following string
resource:
SHOW_CONSOLE=1 APPEND_QUOTE=1
@@COMSPEC@@ /S /C \"\"@@EXEPATH@@\\usr\\bin\\bash.exe\" --login -i
(Note that there are only three quotes on that command-line, the fourth
to be appended due to the `APPEND_QUOTE` setting.)
This is (1/3) to fix https://github.com/git-for-windows/git/issues/396
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When switching the current working directory, say, in PowerShell, it is
quite possible to use a different capitalization than the one that is
recorded on disk. While doing the same in `cmd.exe` adjusts the
capitalization magically, that does not happen in PowerShell so that
`getcwd()` returns the current directory in a different way than is
recorded on disk.
Typically this creates no problems except when you call
git log .
in a subdirectory called, say, "GIT/" but you switched to "Git/" and
your `getcwd()` reports the latter, then Git won't understand that you
wanted to see the history as per the `GIT/` subdirectory but it thinks you
wanted to see the history of some directory that may have existed in the
past (but actually never did).
So let's be extra careful to adjust the capitalization of the current
directory before working with it.
Reported by a few PowerShell power users ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper is also used as a redirector for Git for Windows'
bin\bash.exe dropin: for backwards-compatibility, bin\bash.exe exists
and simply sets up the environment variables before executing the
*real* bash.
However, due to our logic to use the directory in which the `.exe`
lives as top-level directory (or one directory below for certain, known
basenames such as `git.exe` and `gitk.exe`), the `PATH` environment
variable was prefixed with the `/bin/bin` and `/bin/mingw/bin`
directories -- which makes no sense.
Instead, let's just auto-detect the top-level directory in the common
case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We should not conflate the 'exepath' with the 'top-level
directory'. The former should be the directory in which the executable
lives while the latter should be the top-level directory ("POSIX root
directory") as far as Git is concerned.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Just like we support having alternates pointing to different drives, we
want to support alternates pointing to network shares, i.e. UNC paths.
Technically, what we do in this patch is not to support UNC alternates,
but to support UNC paths when normalizing paths. But the latter implies
the former, and the former really was the motivation for this patch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git only colours the output and uses pagination if isatty() returns 1.
MSys and Cygwin emulate pseudo terminals via named pipes, meaning that
isatty() returns 0.
Commit 3adef8de55 fixed this for MSys
terminals, but not Cygwin.
The named pipes that Cygwin and Msys use are very similar. MSys PTY pipes
are called 'msys-*-pty*' and Cygwin uses 'cygwin-*-pty*'. This commit
modifies the existing check to allow both MSys and Cygwin PTY pipes to be
identified as TTYs.
Note that Pagination is still broken on Cygwin. less.exe is spawned (as
seen in Process Explorer and using GIT_TRACE=1), but the output is not
being piped into it.
This partially fixes https://github.com/git-for-windows/git/issues/267
Signed-off-by: Alan Davies <alan.n.davies@gmail.com>
Windows 7 allows users to pin running applications to the task bar. By
setting the application ID, multiple processes can share a single task
bar entry, and this is exactly what we need for `git-bash.exe` which
wants to share the task bar entry with the `mintty.exe` instance it
launches.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The _POSIX_THREAD_SAFE_FUNCTIONS constant is supposed to be defined only
if flockfile() and friends are available. MinGW-w64 defines that
constant, but the functions are not available. Work around that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This branch introduces support for reading the "Windows-wide" Git
configuration from `%PROGRAMDATA%\Git\config`. As these settings are
intended to be shared between *all* Git-related software, that config
file takes an even lower precedence than `$(prefix)/etc/gitconfig`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch adds the --command=<command> option that allows
starting the Git Bash (or Git CMD) with different terminal emulators
than the one encoded via embedded string resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use msysGit's `git-wrapper` instead of the builtins. This works around
two issues:
- when the file system does not allow hard links, we would waste over
800 megabyte by having 109 copies of a multi-megabyte executable
- even when the file system allows hard links, the Windows Explorer
counts the disk usage as if it did not. Many users complained about
Git for Windows using too much space (when it actually did not). We
can easily avoid those user complaints by merging this branch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Between the libgit2 and the Git for Windows project, there has been a
discussion how we could share Git configuration to avoid duplication (or
worse: skew).
Earlier, libgit2 was nice enough to just re-use Git for Windows'
C:\Program Files (x86)\Git\etc\gitconfig
but with the upcoming Git for Windows 2.x, there would be more paths to
search, as we will have 64-bit and 32-bit versions, and the
corresponding config files will be in %PROGRAMFILES%\Git\mingw64\etc and
...\mingw32\etc, respectively.
Worse: there are portable Git for Windows versions out there which live
in totally unrelated directories, still.
Therefore we came to a consensus to use `%PROGRAMDATA%\Git\config` as the
location for shared Git settings that are of wider interest than just Git
for Windows.
On XP, there is no %PROGRAMDATA%, therefore we need to use
"%ALLUSERSPROFILE%\Application Data\Git\config" in those setups.
Of course, the configuration in `%PROGRAMDATA%\Git\config` has the
widest reach, therefore it must take the lowest precedence, i.e. Git for
Windows can still override settings in its `etc/gitconfig` file.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of `git-bash.exe` automatically running the Git Bash in the
home directory was to support the start menu item `Git Bash` (which
should not start in C:\Program Files\Git, but in $HOME), and to make
that behavior consistent with double-clicking in `git-bash.exe`
portable Git.
However, it turns out that one of the main use cases of portable Git is
to run the Git Bash in GitHub for Windows, and it should start in the
top-level directory of a given project. Therefore, the concern to keep
double-clicking `git-bash.exe` consistent with the start menu item was
actually unfounded.
As to the start menu item: it can easily be changed to launch
`git-bash.exe` with a command-line option. So let's introduce the
--cd-to-home option for that purpose.
As a bonus, the Git wrapper can now also serve as a drop-in redirector
/bin/bash.exe to provide backwards-compatibility of Git for Windows 2.x
with 1.x: some 3rd-party software expects to find that executable there,
and it also expects it to leave the working directory unchanged.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
By embedding string resources into the Git wrapper executable, it
can be configured to execute custom commands (after setting up the
environment in the way required for Git for Windows to work properly).
This feature is used e.g. for `git-bash.exe` which launches a Bash in
the configured terminal window.
Here, we introduce command-line options to override those string
resources. That way, a user can call `git-bash.exe` (which is a copy of
the Git wrapper with `usr\bin\bash.exe --login -i` embedded as string
resource) with command-line options that will override what command is
run.
ConEmu, for example, might want to call
...\git-bash.exe --needs-console --no-hide --minimal-search-path ^
--command=usr\\bin\\bash.exe --login -i
In particular, the following options are supported now:
--command=<command-line>::
Executes `<command-line>` instead of the embedded string resource
--[no-]minimal-search-path::
Ensures that only `/cmd/` is added to the `PATH` instead of
`/mingw??/bin` and `/usr/bin/`, or not
--[no-]needs-console::
Ensures that there is a Win32 console associated with the spawned
process, or not
--[no-]hide::
Hides the console window, or not
Helped-by: Eli Young <elyscape@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We will enhance the function in the next commit to support @@VAR@@
expansion in the upcoming `--command=<command>` option.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The contract for the stat() and lstat() function is:
> stat(): stats the file pointed to by path and fills in buf.
> lstat(): is identical to stat(), except that if path is a symbolic link,
> then the link itself is stat-ed, not the file that it refers to.
stat() should always return the statistics of the file or directory a
symbolic link is pointing to. The lstat() function is used to get the
stats for the symlink. Hence the check should not be there.
Signed-off-by: Loris Chiocca <loris@chiocca.ch>
This is needed so that `_wchdir()` can be used with drive root
directories, e.g. C:\ (`_wchdir("C:")` fails to switch the directory
to the root directory).
This fixes https://github.com/msysgit/git/issues/359 (in Git for Windows
2.x only, though).
Likewise, `readlink()`'s semantics require a trailing slash for symbolic
links pointing to directories. Otherwise all checked out symbolic links
pointing to directories would be marked as modified even directly after a
fresh clone.
This fixes https://github.com/git-for-windows/git/issues/210
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Symlinks on Windows have a flag that indicates whether the target is a file
or a directory. Symlinks of wrong type simply don't work. This even affects
core Win32 APIs (e.g. DeleteFile() refuses to delete directory symlinks).
However, CreateFile() with FILE_FLAG_BACKUP_SEMANTICS doesn't seem to care.
Check the target type by first creating a tentative file symlink, opening
it, and checking the type of the resulting handle. If it is a directory,
recreate the symlink with the directory flag set.
It is possible to create symlinks before the target exists (or in case of
symlinks to symlinks: before the target type is known). If this happens,
create a tentative file symlink and postpone the directory decision: keep
a list of phantom symlinks to be processed whenever a new directory is
created in mingw_mkdir().
Limitations: This algorithm may fail if a link target changes from file to
directory or vice versa, or if the target directory is created in another
process.
Signed-off-by: Karsten Blees <blees@dcon.de>
Implement symlink() that always creates file symlinks. Fails with ENOSYS
if symlinks are disabled or unsupported.
Note: CreateSymbolicLinkW() was introduced with symlink support in Windows
Vista. For compatibility with Windows XP, we need to load it dynamically
and fail gracefully if it isnt's available.
Signed-off-by: Karsten Blees <blees@dcon.de>
Implement readlink() by reading NTFS reparse points. Works for symlinks
and directory junctions. If symlinks are disabled, fail with ENOSYS.
Signed-off-by: Karsten Blees <blees@dcon.de>
If symlinks are enabled, resolve all symlinks when changing directories,
as required by POSIX.
Note: Git's real_path() function bases its link resolution algorithm on
this property of chdir(). Unfortunately, the current directory on Windows
is limited to only MAX_PATH (260) characters. Therefore using symlinks and
long paths in combination may be problematic.
Note: GetFinalPathNameByHandleW() was introduced with symlink support in
Windows Vista. Thus, for compatibility with Windows XP, we need to load it
dynamically and behave gracefully if it isnt's available.
Signed-off-by: Karsten Blees <blees@dcon.de>
MSVCRT's _wrename() cannot rename symlinks over existing files: it returns
success without doing anything. Newer MSVCR*.dll versions probably do not
have this problem: according to CRT sources, they just call MoveFileEx()
with the MOVEFILE_COPY_ALLOWED flag.
Get rid of _wrename() and call MoveFileEx() with proper error handling.
Signed-off-by: Karsten Blees <blees@dcon.de>
_wunlink() / DeleteFileW() refuses to delete symlinks to directories. If
_wunlink() fails with ERROR_ACCESS_DENIED, try _wrmdir() as well.
Signed-off-by: Karsten Blees <blees@dcon.de>
Symlinks on Windows don't work the same way as on Unix systems. E.g. there
are different types of symlinks for directories and files, creating
symlinks requires administrative privileges etc.
By default, disable symlink support on Windows. I.e. users explicitly have
to enable it with 'git config [--system|--global] core.symlinks true'.
The test suite ignores system / global config files. Allow testing *with*
symlink support by checking if native symlinks are enabled in MSys2 (via
'MSYS=winsymlinks:nativestrict').
Reminder: This would need to be changed if / when we find a way to run the
test suite in a non-MSys-based shell (e.g. dash).
Signed-off-by: Karsten Blees <blees@dcon.de>
