为什么必须从工作树的顶级目录运行git-bisect？

Question

如果有人试图从存储库的根目录以外的任何地方运行任何git-bisect命令，则会告诉其中一个：

  

您需要从工作树的顶层运行此命令。

为什么？我知道没有其他git命令有这个要求，我认为没有明显的理由，bisect应该是特殊的。手册页也没有提到这个限制。

这真的不是什么大不了的事。我大多只是好奇。

Answer 1

看一下项目中的一些提交，我看到Marcel M. Cary的一个提交（marcel@oak.homeunix.org）

他在提交中说（它恰好是git-pull，但我认为它是相关的）

  

“git pull”失败，因为POSIX shell有一个当前工作的概念   与getcwd（）不同的目录。 shell存储此路径   在PWD。结果，“cd ../”可以在a中被不同地解释   shell脚本比C程序中的chdir（“../”）。 shell解释   “../”通过从中剥离最后一个文本路径组件   PWD，而C chdir（）跟在当前目录中的“..”链接   在文件系统上。当PWD是符号链接时，这些是不同的   目的地。结果，Git的C命令找到了正确的命令   顶级工作树，而shell脚本则没有。

     

https://github.com/git/git/commit/08fc0608657ee91bc85276667804c36a93138c7d

所以我说部分原因是因为git-bisect是一个shell脚本，不能信任它自己找到顶层（当涉及符号链接时）。

Answer 2

平分过程需要检查项目的不同修订。如果特定修订版不包含当前文件夹，则将删除当前文件夹。

在这种情况下，你的shell可能最终会坐在不再在文件系统上的文件夹中！然后Git将无法找到顶级的.git文件夹，因此无需干预就无法继续进行二等分过程。

示范：

$ git rev-parse --show-toplevel
/path/to/project
$ mkdir tmp
$ cd tmp
$ rmdir ../tmp
$ git rev-parse --show-toplevel
fatal: Unable to read current working directory: No such file or directory

当然，在执行git checkout时会出现同样的问题，并且事后可以轻松修复，例如使用cd ..（willoller解释了为什么它在shell中工作但不在git中工作）。

但由于二等分是进程，因此在开始之前避免这种情况是有意义的，特别是如果我们想要使用git bisect run之类的自动化。

Answer 3

  

结果，Git的C命令找到了正确的顶层工作树，而shell脚本找不到了。

好吧，使用Git 2.21（2019年2月），git bisect继续从shell脚本过渡到C。

请参见commit 06f5608，commit 450ebb7，commit 129a6cf，commit 4fbdbd5，commit e3b1e3b，commit 0f30233，commit 5e82c3d（2019年1月2日）由Pranit Bauva (pranitbauva1997)。
帮助者：Ramsay Jones (jeffhostetler)和Stephan Beyer (sbeyer)。
^{（由Junio C Hamano -- gitster --在commit 09a9c1f中合并，2019年2月7日）}

  

bisect--helper：bisect_start shell函数部分使用C

     

在C中重新实现bisect_start shell函数，然后添加   bisect-start的{​​{1}}子命令以从   git-bisect.sh。

     

最后一部分未转换，因为它调用了另一个Shell函数。   git bisect--helper之后将完成bisect_start shell函数   shell函数已移植到C中。

这还没有完成，但是迁移的副作用是可以从子文件夹执行bisect_next。