Worktree placed under a symlinked directory confuses git #1676

kenneth-olwing · 2018-05-14T14:12:12Z

[x ] I was not able to find an open or closed issue matching what I'm seeing

Setup

Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.17.0.windows.1
cpu: x86_64
built from commit: e7621d891d081acff6acd1f0ba6ae0adce06dd09
sizeof-long: 4

Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.16299.371]

What options did you set as part of the installation? Or did you choose the
defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

No such file - using the portable build

Any other interesting things about your environment that might be related
to the issue you're seeing?

Not at the moment

Details

Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

cmd.exe

What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.

C:\>mkdir MyRoot

C:\>mklink /d MyRootLink MyRoot
symbolic link created for MyRootLink <<===>> MyRoot

C:\>cd MyRootLink

C:\MyRootLink>mkdir MyNewProj

C:\MyRootLink>cd MyNewProj

C:\MyRootLink\MyNewProj>git init
Initialized empty Git repository in C:/MyRootLink/MyNewProj/.git/

C:\MyRootLink\MyNewProj>git stash
fatal: C:\ken1\Git\mingw64/libexec/git-core\git-stash cannot be used without a working tree.

C:\MyRootLink\MyNewProj>git rev-parse --is-inside-work-tree
false

What did you expect to occur after running these commands?

Stash should not give that message and the rev-parse should say true.

What actually happened instead?

Stash gives a non-sensical error message and rev-parse gives a false result.

After investigation I tracked it down to my use of symlinks above the worktree, Moving to the 'real' directory makes the commands work as expected.

The text was updated successfully, but these errors were encountered:

As pointed out in git-for-windows#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 <[email protected]>

dscho · 2020-01-01T20:14:16Z

Turns out that the git stash command was rewritten in C in the meantime, which worked around the issue, and I just opened a PR for the git rev-parse --is-inside-work-tree issue.

kenneth-olwing · 2020-01-02T19:01:52Z

Thank you for your feedback!

dscho · 2020-01-03T19:35:08Z

I just merged it. @kenneth-olwing Could I ask you to test the next snapshot (I might also get v2.25.0-rc1 out today)?

As pointed out in git-for-windows#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 <[email protected]>

dscho · 2020-01-03T22:11:46Z

@kenneth-olwing Could you please test with github.com/git-for-windows/git/releases/tag/v2.25.0-rc1.windows.1?

As pointed out in #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 <[email protected]>

kenneth-olwing · 2020-01-04T20:34:59Z

Sorry to be a bit behind the curve :-), but yes, it works for me (used the portable version).

Thanks, have a good 2020!

As pointed out in #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 <[email protected]>

dscho · 2020-01-04T21:44:35Z

@kenneth-olwing thanks for testing!

As pointed out in #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 <[email protected]>

As pointed out in git-for-windows#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 <[email protected]>

As pointed out in #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 <[email protected]>

dscho mentioned this issue Jan 1, 2020

Do resolve symlinks in getcwd() #2449

Merged

dscho added this to the Next release milestone Jan 3, 2020

dscho closed this as completed Jan 3, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Worktree placed under a symlinked directory confuses git #1676

Worktree placed under a symlinked directory confuses git #1676

kenneth-olwing commented May 14, 2018

dscho commented Jan 1, 2020

Uh oh!

kenneth-olwing commented Jan 2, 2020

Uh oh!

dscho commented Jan 3, 2020

Uh oh!

dscho commented Jan 3, 2020

Uh oh!

kenneth-olwing commented Jan 4, 2020

Uh oh!

dscho commented Jan 4, 2020

Uh oh!

Worktree placed under a symlinked directory confuses git #1676

Worktree placed under a symlinked directory confuses git #1676

Comments

kenneth-olwing commented May 14, 2018

Setup

Details

dscho commented Jan 1, 2020

Uh oh!

kenneth-olwing commented Jan 2, 2020

Uh oh!

dscho commented Jan 3, 2020

Uh oh!

dscho commented Jan 3, 2020

Uh oh!

kenneth-olwing commented Jan 4, 2020

Uh oh!

dscho commented Jan 4, 2020

Uh oh!