diff options
| author | Johannes Schindelin <johannes.schindelin@gmx.de> | 2026-01-09 20:05:05 +0000 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2026-01-09 18:28:35 -0800 |
| commit | f0af8b4aae3397d6bbe68a3c09f558cab983eaff (patch) | |
| tree | 04c2e1251752c18840033aead85fa5c0f1bdbc87 /contrib/persistent-https | |
| parent | Merge branch 'js/test-symlink-windows' into js/prep-symlink-windows (diff) | |
| download | git-f0af8b4aae3397d6bbe68a3c09f558cab983eaff.tar.gz git-f0af8b4aae3397d6bbe68a3c09f558cab983eaff.zip | |
mingw: do resolve symlinks in `getcwd()`
As pointed out in https://github.com/git-for-windows/git/issues/1676,
the `git rev-parse --is-inside-work-tree` command currently fails when
the current directory's path contains symbolic links.
The underlying reason for this bug is that `getcwd()` is supposed to
resolve symbolic links, but our `mingw_getcwd()` implementation did not.
We do have all the building blocks for that, though: the
`GetFinalPathByHandleW()` function will resolve symbolic links. However,
we only called that function if `GetLongPathNameW()` failed, for
historical reasons: the latter function was supported for a long time,
but the former API function was introduced only with Windows Vista, and
we used to support also Windows XP. With that support having been
dropped, we are free to call the symbolic link-resolving function right
away.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/persistent-https')
0 files changed, 0 insertions, 0 deletions