git bisect is not junction-aware

[Pomax]

• 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.19.0.windows.1
cpu: x86_64
built from commit: d96bb8bc6c636a8869140e860e72e7bdf64bd790
sizeof-long: 4
sizeof-size_t: 8

• 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.17134.590]

• 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"

Editor Option: VisualStudioCode
Path Option: CmdTools
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Disabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Builtin Rebase: Disabled
Enable Builtin Stash: Disabled

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

The main git direction is a junction, made with:

C:\Users\Mike\Documents\> mklink \D "git" "J:\Junctions\Users\Mike\Documents\Git"

So all any project cloned into C:\Users\Mike\Documents\git will show up as expected, with the actual data residing on the J: drive, instead.

Details

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

all of them

• 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.

git bisect start

• What did you expect to occur after running these commands?

I expected git to start a bisect.

• What actually happened instead?

Git cites:

You need to run this command from the toplevel of the working tree.

Which is weird, because the dir the command is issued in is the toplevel working tree (it houses the .git dir). However, this explains why git is getting confused:

c:\Users\Mike\Documents\git\projects\mj>git rev-parse --show-toplevel
J:/Junctions/Users/Mike/Documents/Git/projects/mj

And that's plain wrong: that junction should be invisible, just as a symlink is in POSIX environments.

[PhilipOakley]

Junctions and Reparse points are a source of much frustration and confusion relative to nix/POSIX symlinks. It's not my area of expertise. However do search through the issues of the last year or so for discussions about how the symlinks are handled and past issues (our support includes Vista but not XP)

[PhilipOakley]

I used Junctions Reparse points updated:>=2019-02-01 and found #437 #607 #2172. See if any of those help.

[Pomax]

given that 2172 is this issue, and 607 is about symlink targets getting deleted during clean (instead of the symlink itself), neither of those help ;)

437 feels like it's half-related: it's about mingw/msys treating junctions as mount points, instead of as symlinks, and so git will do what it does for mount points already - which is kind of a false analogy since junctions are much closer to symlinks than they are to mount points, and even now that win10 supports true symlinks, the command for them (mklink) creates "links" that are either true symlinks or junctions, depending on the user's permissions which makes it pretty clear that Windows considers junctions a form of link, not a mounted volume.

(if you run mklink, then elevated permissions build a junction without asking you to specify, and standard user execution yields a symlink, without asking you)

So with that said: the issue here is making sure git treats a dir as "the root directory" during bisect when that dir is a junction for the root directory. We're already "at the top" of the repo, and any commands issued at this location should work identically irrespective of whether the aliased or true directory is used as far as the OS is concerned.

Note that this is specifically for the bisect command, as no other command that I know of has this "you need to be at the root of the repo" requirement.

[dscho]

437 feels like it's half-related: it's about mingw/msys treating junctions as mount points, instead of as symlinks

Careful with comments like this one: it can easily suggest that you're not half as familiar with the matter as you think you are.

which is kind of a false analogy since junctions are much closer to symlinks than they are to mount points

This is simply incorrect.

Symbolic links are resolved in user space, mount points are resolved in kernel space. Junction points are resolved in kernel space. So there.

c:\Users\Mike\Documents\git\projects\mj>git rev-parse --show-toplevel
J:/Junctions/Users/Mike/Documents/Git/projects/mj

And that's plain wrong: that junction should be invisible, just as a symlink is in POSIX environments.

I understand that you are frustrated, and as such want to vent.

But this overly simplistic reasoning is not really helpful. It actually wants me to run away from this ticket. And I would be your best bet to see your issue resolved.

[Pomax]

I will happily apologise for getting things wrong, and coming off as venting - all I've been able to find in the past that's understandable to a regular user of windows has suggested that junctions are window's way to offer users symlinks, and so I've operated under that assumption (the fact that now that windows will offer real symlinks, it will still build junctions if you're running as admin, does not help make their use any clearer).

As a windows user, I have no real experience with kernel space vs. user space, so I'm more than happy to learn and acknowledge I'm wrong - so in terms of this issue: it feels like git bisect should be able to determine that it's already at the root or my project (because that's what every other windows utility I use has conditioned me to understand things as working as: anything I do to a junctioned dir will run apparently completely unaware of the fact that there is a junction)

[dscho]

Okay, let's get back to the reported issue.

The main git direction is a junction, made with:

C:\Users\Mike\Documents\> mklink \D "git" "J:\Junctions\Users\Mike\Documents\Git"

This fails for me with

The syntax of the command is incorrect.

I have to use a forward slash for /d, \d does not work.

And when I do that, in a CMD with Git v2.22.0-rc3, and then call git bisect start, it works.

When I replace the /d with a /j (to create a junction point instead of a symlink), it works.

So maybe some patch that we integrated since v2.19.0 fixed your issue. Could you re-test with https://github.com/git-for-windows/git/releases/tag/v2.22.0-rc3.windows.1?

[Pomax]

Hm, even with 2.22.0-rc3, git bisect doesn't like it:

C:\Users\Mike\Documents\Git\projects\mj>git --version
git version 2.22.0.rc3.windows.1

C:\Users\Mike\Documents\Git\projects\mj>git bisect start
You need to run this command from the toplevel of the working tree.

C:\Users\Mike\Documents\Git\projects\mj>git rev-parse --show-toplevel
J:/Junctions/Users/Mike/Documents/Git/projects/mj

I mklink'ed the Documents folder, which at the time was a junction, and is currently a windows symlink (I changed it after originally filing, to see if that made any difference):

C:\Users\Mike>dir /al
 Volume in drive C is System
...
2019-02-05  02:52 PM    <SYMLINKD>     Documents [J:\Junctions\Users\Mike\Documents]
...

[Pomax]

Just as a sanity check, I also ran bisect in the "true" location, and that works fine:

j:\Junctions\Users\Mike\Documents\Git\projects\mj>git bisect start

j:\Junctions\Users\Mike\Documents\Git\projects\mj>git bisect reset
Already on 'client-server'

j:\Junctions\Users\Mike\Documents\Git\projects\mj>

[dscho]

I ran my tests on Microsoft Windows [Version 10.0.18362.113]. That's the difference I could imagine explains our opposite experiences.

I tried again, and creating a symlink via mklink /d showed the current directory as output of git rev-parse --show-toplevel.

[Pomax]

Ah. I'm currently on Microsoft Windows [Version 10.0.17134.590]. I've not heard anything crazy about the May update this time round, so I can try to upgrade to that after (PST) work hours and see if I can confirm things working post-update.

[Pomax]

Hm, well that literally wiped my user profile and every single serial I ever activated any software with, so I had to roll back to this morning's backup.... guess I won't be testing this on the latest windows 10 update until I can actually stand to lose an entire day on "figuring out how to safely apply that update" =(

[dscho]

@Pomax from your GitHub profile, it looks like you're more of a node.js person than a C one. If you have some C fu in you, I will happily guide you through debugging this issue in your setup.

[dscho]

Oh, one idea just occurred to me. Maybe the problem has to do with your F: drive? You could try with a symbolic link to the C: drive to test that hypothesis.

[Pomax]

The only C I've used is C++, and that was mostly a follow-along for a tutorial that explained how to write a simple VST plugin. That said, I'm up for following instructions and seeing where that gets us. I'll give the local symlink a try, too.

[Pomax]

with a symlink set up for a git dir, every attempt works fine, both on C and on the junction SSD, regardless of symlink or junction...

So it might also somehow be related to the fact that the entire user profile is symlinked? =/

[dscho]

So it might also somehow be related to the fact that the entire user profile is symlinked? =/

No idea... all I know for sure is that I cannot reproduce this issue on my side.

[dscho]

Let's close this until we have a reliable way to reproduce this.

[Pomax]

fair enough