如果 '/' 是存储库的根目录，为什么 git 会中断？

Question

我们想使用 git 来维护系统配置。因为有时配置数据存在于 /etc 之外，我们已经开始在我们的系统上做这样的事情：

  # cd /
  # git init
  # git add etc
  # git add some/other/path
  # git commit -m 'initial import'

等等。这在一定程度上有效。只要您的 cwd == '/'，git 就会正常运行。但是，例如，如果您尝试从子目录中运行 git：

cd /etc
git status

你得到了垃圾。在我们的例子中，数千行“已删除：”列表中的文件显然仍然存在。这种行为似乎是在 / 中运行 git 所独有的；在其他任何地方做同样的事情都很好。

我可以像这样“修复”这种行为：

GIT_WORK_TREE=/ git status

嘿，一切都按照 Linus 的预期进行……但这很痛苦。我不想单方面在环境中设置它（因为这会与在其他存储库中使用 git 冲突），并且我想避免使用包装脚本。我还有其他选择吗？

Answer 1

这是一个完整的猜测，您可以用它来进一步调查，但我怀疑 git 的“查找 .git 目录”行为与 / 是它自己的父级这一事实相互作用目录。也许“停在根”逻辑有一个栅栏类型错误。

Answer 2

在存储库上设置 core.worktree 选项可以很好地解决这个问题：

git config core.worktree /

这比在环境中设置 GIT_WORK_TREE 效果好得多。耶！

Answer 3

这将在 Git 2.4.1+（2015 年第二季度）中得到修复。
参见commit 84ccad8 by Jeff King (peff)，并在7502b23 中合并。

init：初始化/.git时不要设置core.worktree

如果您在根目录中使用“git init /”创建 git 存储库，我们会错误地写入 core.worktree 条目。
这没有错误，因为当我们不需要时设置core.worktree 是可以的。但是，如果您稍后将 .git 目录移动到另一个路径（这通常会移动相对工作树，但如果存在显式工作树集，则会被阻止），这无疑是令人惊讶的。

问题是我们通过查看是否可以通过将“/.git”连接到工作树上来创建 git_dir 来检查 core.worktree 是否必要。
在这种情况下，这将导致“//.git”，但我们实际上有“/.git” （没有双斜线）。

（这就是为什么core.worktree在这里设置不正确，当git init在根文件夹/完成时）

我们可以通过对根目录进行特殊处理来解决这个问题。我还将逻辑拆分为它自己的函数，以使条件更具可读性（并使用了 skip_prefix，我认为这使得发生的事情更加明显）。

没有测试，因为我们需要能够写入“/”才能这样做。
我确实手动确认了：

sudo git init /
cd /
git rev-parse --show-toplevel
git config core.worktree

仍能正确找到顶层（如“/”），并且没有设置任何 core.worktree 变量。