When performing a rebase, rmdir() is called on the folder .git/logs. On
Unix rmdir() exits without deleting anything in case .git/logs is a
symbolic link but the equivalent functions on Windows (_rmdir, _wrmdir
and RemoveDirectoryW) do not behave the same and remove the folder if it
is symlink even if it is not empty.
It generates issues when folders in .git/ are symlinks which is
especially the case when git-repo[1] is used.
This commit updates mingw_rmdir() so that its behavior is the same as
Linux rmdir() in case of symbolic links.
[1]: git-repo is a python tool built on top of Git which helps manage
many Git repositories. It stores all the .git/ folders in a central
place by taking advantage of symbolic links.
More information: https://gerrit.googlesource.com/git-repo/
Signed-off-by: Thomas Bétous <tomspycell@gmail.com>
As mentioned in the Makefile and CMakeLists.txt: "When cross-compiling, define HOST_CPU as the canonical name of the CPU on which the built Git will run (for instance "x86_64")"
This commit sets the HOST_CPU variable since Git for Windows arm64 is cross-compiled from an amd64 host.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Git's regular Makefile mentions that HOST_CPU should be defined when cross-compiling Git: 37796bca76/Makefile (L438-L439)
This is then used to set the GIT_HOST_CPU variable when compiling Git: 37796bca76/Makefile (L1337-L1341)
Then, when the user runs `git version --build-options`, it returns that value: 37796bca76/help.c (L658)
This commit adds the same functionality to the CMake configuration. Users can now set -DHOST_CPU= to set the target architecture.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Visual Studio Code _just_ introduced a new, neat feature, where clicking
on a badge can open the repository really quickly, without having to
clone it (e.g. when fixing typos or things like that).
Let's add that badge to our README.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's keep avoiding the `*A()` family of Win32 API functions because
they are susceptible to incoherent encoding problems. In Git for
Windows, we always assume paths to be UTF-8 encoded. Let's use the
dedicated helper to convert such a path to the wide character version,
and then use the `*W()` function instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a section instructing developers how to build, and how to test the
just-built executables in-place.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This adds support for a new http.sslAutoClientCert config value.
In cURL 7.77 or later the schannel backend does not automatically send
client certificates from the Windows Certificate Store anymore.
This config value is only used if http.sslBackend is set to "schannel",
and can be used to opt in to the old behavior and force cURL to send
client certificates.
This fixes https://github.com/git-for-windows/git/issues/3292
Signed-off-by: Pascal Muller <pascalmuller@gmail.com>
We query `TIOCGWINSZ` in Git to determine the correct value for
`COLUMNS`, and then set that environment variable.
If `TIOCGWINSZ` is not available, we fall back to the hard-coded value
80 _and still_ set the environment variable.
On Windows this is a problem. The reason is that Git for
Windows uses a version of `less` that relies on the MSYS2 runtime to
interact with the pseudo terminal (typically inside a MinTTY window,
which is also aware of the MSYS2 runtime). Both MinTTY and `less.exe`
interact with that pseudo terminal via `ioctl()` calls (which the MSYS2
runtime emulates even if there is no such thing on Windows).
Since https://github.com/gwsw/less/commit/bb0ee4e76c2, `less` prefers
the `COLUMNS` variable over asking ncurses itself.
But `git.exe` itself is _not_ aware of the MSYS2 runtime, or for that
matter of that pseudo terminal, and has no way to call `ioctl()` or
`TIOCGWINSZ`.
Therefore, `git.exe` will fall back to hard-coding 80 columns, no matter
what the actual terminal size is.
But `less.exe` is totally able to interact with the MSYS2 runtime and
would not actually require Git's help (which actually makes things
worse here). So let's not override `COLUMNS` on Windows.
Let's just not set `COLUMNS` unless we managed to query the actual value
from the terminal.
This fixes https://github.com/git-for-windows/git/issues/3235
Co-authored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since we're now watching out for new libgcrypt versions, let's also
watch out for its dependency libgpg-error.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's watch out for new libgcrypt versions, too (this component is a
pretty important dependency of gnupg).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, both forward and backslash are valid separators. In
22d5507493 (subtree: don't fuss with PATH, 2021-04-27), however, we
added code that assumes that it can only be the forward slash.
Let's fix that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 22d5507493 (subtree: don't fuss with PATH, 2021-04-27), `git
subtree` was broken thoroughly on Windows.
The reason is that it assumes Unix semantics, where `PATH` is
colon-separated, and it assumes that `$GIT_EXEC_PATH:` is a verbatim
prefix of `$PATH`. Neither are true, the latter in particular because
`GIT_EXEC_PATH` is a Windows-style path, while `PATH` is a Unix-style
path list.
Let's make extra certain that `$GIT_EXEC_PATH` and the first component
of `$PATH` refer to different entities before erroring out.
We do that by using the `test <path1> -ef <path2>` command that verifies
that the inode of `<path1>` and of `<path2>` is the same.
Sadly, this construct is non-portable, according to
https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html.
However, it does not matter in practice because we still first look
whether `$GIT_EXEC_PREFIX` is string-identical to the first component of
`$PATH`. This will give us the expected result everywhere but in Git for
Windows, and Git for Windows' own Bash _does_ handle the `-ef` operator.
Just in case that we _do_ need to show the error message _and_ are
running in a shell that lacks support for `-ef`, we simply suppress the
error output for that part.
This fixes https://github.com/git-for-windows/git/issues/3260
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the built-in FSMonitor receives an invalid v2 token, we do not
actually need to wait for a cookie file. There simply is no use for
waiting in this instance. It's not like the client will all of a sudden
realize that it sent an incorrect token and somehow make up a correct
token from thin air in a follow-up query.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In FSMonitor v1, we made sure to only use a valid `since_token` when
querying the FSMonitor. This condition was accidentally lost in v2, and
caused segmentation faults uncovered by Scalar's Functional Tests.
I had tried to fix this in https://github.com/git-for-windows/pull/3241,
but the fix was incomplete, and I had to follow up with
https://github.com/git-for-windows/pull/3258. However, it turns out that
both of them were actually only work-arounds; I should have dug deeper
to figure out _why_ the `since_token` was no longer guaranteed not to be
`NULL`, and I finally did.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the built-in FSMonitor receives an unexpected token, we do not
actually need to wait for a cookie file. There simply is no use for
waiting in this instance. It's not like the client will all of a sudden
realize that it sent an incorrect token and somehow make up a correct
token from thin air in a follow-up query.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When flushing the FSMonitor data, we do not actually need to wait for a
cookie file. In the worst case, we will over-report a bit.
If we _do_ wait for a cookie file, in the worst case we cause a hang
because the FSMonitor daemon will wait and wait even though the `.git/`
directory might be gone already.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch re-adds the deprecated --stdin/-z options to `git
reset`. Those patches were overridden by a different set of options in
the upstream Git project before we could propose `--stdin`.
We offered this in MinGit to applications that wanted a safer way to
pass lots of pathspecs to Git, and these applications will need to be
adjusted.
Instead of `--stdin`, `--pathspec-from-file=-` should be used, and
instead of `-z`, `--pathspec-file-nul`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This branch allows third-party tools to call `git status
--no-lock-index` to avoid lock contention with the interactive Git usage
of the actual human user.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These are Git for Windows' Git GUI and gitk patches. We will have to
decide at some point what to do about them, but that's a little lower
priority (as Git GUI seems to be unmaintained for the time being, and
the gitk maintainer keeps a very low profile on the Git mailing list,
too).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is the recommended way on GitHub to describe policies revolving around
security issues and about supported versions.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
