Question

我主要在Linux上工作，但我也有一台Windows VM，主要用于在Windows上运行单元测试。

在Linux中，我有一个Git存储库，可以使用VirtualBox共享文件夹从Windows VM访问。我没有在Windows上使用Git，除了我们的构建系统，它记录当前的Git哈希以将其包含在可执行文件中（运行git describe --always --dirty）。

现在，每次我在Linux或Windows上使用Git，然后再在另一个系统上使用Git，都需要一段时间。例如：

  Linux$ git status
  Linux$ git status # fast (<1s)
Windows$ git status # takes a few dozen seconds
Windows$ git status # fast (<1s)
  Linux$ git status # takes a few seconds
  Linux$ git status # fast (<1s)

我能做些什么来阻止这种情况发生吗？我可以在Windows上关闭Git功能，因为它只需要获取哈希值。但是，我无法改变获取此哈希的方式，因为这在构建系统中很深。我也不希望在Linux和Windows上有单独的存储库，并且彼此提交/推送，因为这会导致更大的开销。

Linux git版本：2.11.0。

Windows git版本：2.14.1.windows.1。

Answer 1

您在这里看到的是Git索引在用作缓存时的效果。

除了它所做的所有其他工作之外，Git的索引充当有关工作树的数据缓存，以加快文件系统操作 - 实际上，跳过文件系统操作，如果可能。它通过记录有关文件的统计信息（以及秘密的目录，即使Git实际上并不存储目录）来实现这一点。此缓存仅在许多条件成立时有效。如果没有，Git必须在工作树上执行昂贵的文件系统操作，正如您所看到的，在Linux上花费时间秒，在Windows上甚至更慢。

共享文件夹违反了缓存假设。特别是，索引中的一个项目是工作树的路径，并且Linux系统内的路径与Windows VM中的路径不同。（无论两个系统如何托管，这通常都是正确的。）

有几种明显的方法可以解决这个问题：

不要分享工作树。这可能是最好的方法。
不允许其中一个系统更新索引（通过将其设置为只读 - 这可能有点棘手）。
在其中一个系统上使用单独的索引：默认索引为$GIT_DIR/index，其中$GIT_DIR来自环境，或默认来自git rev-parse --git-dir，但将GIT_INDEX_FILE设置为路径名将覆盖此。

我建议方法1的原因是，如果您的Git至少是2.5版，则使用git worktree add将其内置到Git中。请注意，每个Git工作树必须位于自己的分支中，或者使用分离的HEAD;为此目的，分离的HEAD方法可能很好，只需使用git checkout --detach <branch>进行更新。

在Windows VM和Linux主机之间共享Git存储库

1 个答案: