Search code examples
windowsgitupgrade

'git rev-parse --is-inside-work-tree' doesn't recognize working tree or subdirectories


After updating to the latest Windows Git (2.5.0 from 1.6.2) I find I'm unable to rebase a branch:

C:\core\guidewire\Dev\2.4>git checkout fhcf-assumptiondate && git rebase master
Previous HEAD position was d032e17... Merge branch 'de8041'
Switched to branch 'fhcf-assumptiondate'
First, rewinding head to replay your work on top of it...
fatal: C:\Program Files\Git\mingw64/libexec/git-core\git-am cannot be used without a working tree.

Comments on this question hint at a Git installation conflict, but the old version is entirely removed by now, including a lingering DLL and checking for stale environment vars.

Looking inside the git scripts, I find that the error message is coming from a test in git-sh-setup that uses git rev-parse --is-inside-work-tree. Consulting rev-parse directly shows that it seems to not understand that I really am inside the working copy:

C:\core\guidewire\Dev\2.4>dir .git
 Volume in drive C is System (Local)
 Volume Serial Number is D4EC-4ED4

 Directory of C:\core\guidewire\Dev\2.4

08/04/2015  21:16                27 .git
               1 File(s)             27 bytes
               0 Dir(s)  155,451,965,440 bytes free

C:\core\guidewire\Dev\2.4>git rev-parse --is-inside-work-tree
false

...Except some commands are able to correctly tell the difference:

C:\core\guidewire\Dev\2.4>git status
HEAD detached from refs/heads/fhcf-assumptiondate
nothing to commit, working directory clean

C:\core\guidewire\Dev\2.4>cd ..

C:\core\guidewire\Dev>git status
fatal: Not a git repository (or any of the parent directories): .git

What is making Git confused about whether I'm in the right directory or not?

Possible points of interest:

  • Repo was created by the previous installation.
  • 1.6.2 was an msys build of Git. 2.5.0 is MinGW.
  • The repo was cloned with --separate-git-dir.
  • checkout, status, add, commit and possibly others all have worked without issue since the upgrade.
  • A clone of the broken repository exhibits correct behavior; 'in' or 'out' of the working tree are detected correctly.

Solution

  • To continue using an existing (1.6.x-created) repository after upgrading to Windows Git 2.5, update the repo's gitconfig:

    [core]
        worktree = c:/core/guidewire/Dev/2.4
    

    to

    [core]
        worktree = C:/core/guidewire/Dev/2.4
    

    The new Git installation either obtains paths differently from the old, or is no longer case-insensitive about paths. Therefore the existing repo working tree location becomes wrong since no folder under c:\core\guidewire\Dev\2.4 will have a prefix of C:\core\guidewire\Dev\2.4. Git source for the current version shows no sign of case-insensitivity, so the msys fork may have modified the path-checking function, or case-smashed all paths prior to comparison.