As suggested privately to Brendan Forster by some unnamed person
(suggestion for the future: use the public mailing list, or even the
public GitHub issue tracker, that is a much better place to offer such
suggestions), we should make use of gcc's stack smashing protector that
helps detect stack buffer overruns early.
Rather than using -fstack-protector, we use -fstack-protector-strong
because it strikes a better balance between how much code is affected
and the performance impact.
In a local test (time git log --grep=is -p), best of 5 timings went from
23.009s to 22.997s (i.e. the performance impact was *well* lost in the
noise).
This fixes https://github.com/git-for-windows/git/issues/501
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was a bug in the wrapper where it would interpolate incorrectly if
the name of the environment variable to expand was longer than the value.
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>
Adjust commit message as follows:
git-gui (Windows): use git-bash.exe if it is available
Git for Windows 2.x ships with an executable that starts the Git Bash
with all the environment variables and what not properly set up. It is
also adjusted according to the Terminal emulator option chosen when
installing Git for Windows (while `bash.exe --login -i` would always
launch with Windows' default console).
So let's use that executable (usually C:\Program Files\Git\git-bash.exe)
instead of `bash.exe --login -i` if its presence was detected.
This fixes https://github.com/git-for-windows/git/issues/490
Signed-off-by: Thomas Kläger <thomas.klaeger@10a.ch>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
mingw-w64-crt provides a basename() function, but it does not do what we
want. For example, it shortens `path0/` to `path`!
So let's not use it (i.e. let's revert commit 00bc8c9ea).
This fixes https://github.com/git-for-windows/git/issues/494
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>
In Windows, a double slash in the beginning of an absolute path denotes
network paths of the form `\\localhost\share\file`. In Git for Windows'
context, the same form is also available with forward slashes.
Let's not start the path in the URL with a double slash (e.g.
`ssh://host//usr/src/git/t/file`) but take pains to use the normalized
form with a single slash, so that Git is not confusing the path for a
UNC one.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch addresses the bug where Git for Windows 2.x' Git GUI
failed to generate a working shortcut via Repository>Create Desktop
Shortcut.
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>
When `git clone` is asked to dissociate the repository from the
reference repository whose objects were used, it is quite possible that
the pack files need to be repacked. In that case, the pack files need to
be deleted that were originally hard-links to the reference repository's
pack files.
On platforms where a file cannot be deleted if another process still
holds a handle on it, we therefore need to take pains to release all
pack files and indexes before dissociating.
This fixes https://github.com/git-for-windows/git/issues/446
The test case to demonstrate the breakage technically does not need to
be run on Linux or MacOSX. It won't hurth, either, though.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files that are in use cannot be removed or renamed. That
means that we have to release pack files when we are about to, say,
repack them. Let's introduce a convenient function to close them
pack files.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was a lot of repeated code to close the file descriptor of
a given pack. Let's just refactor this code into a single function.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, dissociating from a reference can fail very easily due to
pack files that are still in use when they want to be removed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When calling `Repository>Create Desktop Shortcut`, Git GUI assumes
that it is okay to call `wish.exe` directly on Windows. However, in
Git for Windows 2.x' context, that leaves several crucial environment
variables uninitialized, resulting in a shortcut that does not work.
To fix those environment variable woes, Git for Windows comes with a
convenient `git-gui.exe`, so let's just use it when it is available.
This fixes https://github.com/git-for-windows/git/issues/448
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
MSys2 might *look* like Cygwin, but it is *not* Cygwin... Unless it
is run with `MSYSTEM=MSYS`, that is.
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>
When `git clone` is asked to dissociate the repository from the
reference repository whose objects were used, it is quite possible that
the pack files need to be repacked. In that case, the pack files need to
be deleted that were originally hard-links to the reference repository's
pack files.
On platforms where a file cannot be deleted if another process still
holds a handle on it, we therefore need to take pains to release all
pack files and indexes before dissociating.
This fixes https://github.com/git-for-windows/git/issues/446
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>
This makes sure that Git's idea of the current working directory matches
what is recorded on disk (which should be the same as Git's idea).
This helps in particular PowerShell users where the current working
directory can differ in case from what's stored on disk.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This was probably missed because nobody had a left-over `trash/`
directory and the `-f` flag made sure that no error message was
produced when the file was not found that *actually* wanted to
be removed.
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>
