Question

在更新到最新的Windows Git（1.6.2中的2.5.0）之后，我发现我无法重新分支一个分支：

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.

关于this question的评论提示Git安装冲突，但旧版本现在已完全删除，包括一个延迟的DLL并检查过时的环境变量。

查看git脚本，我发现错误消息来自使用git rev-parse --is-inside-work-tree的git-sh-setup中的测试。咨询rev-parse直接表明它似乎不明白我真的在工作副本中：

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

...除了某些命令能够正确区分：

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

是什么让Git对我是否在正确的目录中感到困惑？

可能感兴趣的点：

Repo是由之前的安装创建的。
1.6.2是一个msys构建的Git。 2.5.0是MinGW。
使用--separate-git-dir克隆了回购。
checkout，status，add，commit以及其他所有人都可以毫无问题地工作。
破坏的存储库的克隆表现出正确的行为; ＆＃39;在＆＃39;或者＆＃39; out＆＃39;正确检测到工作树的结构。

Answer 1

要在升级到Windows Git 2.5后继续使用现有的（1.6.x创建的）存储库，请更新repo的gitconfig：

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

到

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

新的Git安装要么获得与旧路径不同的路径，要么不再对路径不区分大小写。因此，现有的repo工作树位置会出错，因为c:\core\guidewire\Dev\2.4下的任何文件夹都不会有C:\core\guidewire\Dev\2.4的前缀。 Git source for the current version没有显示不区分大小写的迹象，因此msys fork可能已经修改了路径检查功能，或者在比较之前对所有路径进行了大小写。

＆＃39; git rev-parse --is-inside-work-tree＆＃39;不识别工作树或子目录

是什么让Git对我是否在正确的目录中感到困惑？

1 个答案: