git status 耗时太长

Question

我正在做一个版本控制系统是 SVN 的项目，我想使用 git。我做了一个 git svn clone 但git status 工作得非常慢（大约 8 分钟）。该存储库有大约 63000 个文件，其中大部分是 git 忽略的库。这是正常的吗？我做了一个git prune && git gc 来清理无法访问的对象和垃圾收集。我也做了一个git repack -Adf，但这让事情变得更糟。甚至需要更长的时间（超过 20 分钟）。

我做错了什么？这是一个 Visual Studio 项目，我假设 .gitignore 文件不包含正确的内容。是否可以准确找出哪些文件是从 Visual Studio 构建中生成的，哪些文件必须进行版本控制？

如果.gitignore 文件不是问题，我怎样才能让我的git status 更快，对于一个有 65000 个文件（大约 10GB）的项目来说，用 git 运行这么慢是否正常？

Answer 1

对于这种大小的存储库，git status 和相关命令可能会非常慢。当项目被分开和分离时，Git 工作得更好，而 Subversion 倾向于鼓励使用包含多个项目的单个庞然大物存储库，因此在使用 Git-SVN 时这类问题并不少见。

不过，您可以使用几种不同的解决方案来加快速度：

• 如果您还没有升级，请升级到使用固态磁盘而不是磁盘。当我在一个类似的存储库上工作时，这个单一的变化对 Git 的速度产生了巨大的影响

• 查看git help svn 的配置部分。这描述了设置 Git-SVN 以使用 Subversion 存储库中的轨道子文件夹（例如 trunk/project-a、branches/*/project-a、tags/*/project-a，...）而不是整个存储库。如果这对您的存储库有意义，则意味着您可以拥有更小的签出次数和更快的git status 运行速度。

• 查看git help read-tree 的稀疏结帐部分。这将告诉你如何设置 Git 以使用稀疏工作副本，类似于 Subversion 稀疏检出。同样，这意味着 Git 在您的工作副本中跟踪的文件将更少，因此检查它们将再次更快。

• 考虑在工作副本的大部分区域设置“假定不变”标志。这将告诉 Git 不要检查文件是否已更改。有两种方法可以做到这一点：

  1. 要为特定文件夹设置标志，请运行以下命令：

     find <folder-name>... -type f -exec git update-index --assume-unchanged {} +
     

  2. 为整个存储库设置标志（注意这将丢失未提交的更改）：

     git config core.ignorestat true
     git reset --hard HEAD
     

  查看git help update-index 中的--assume-unchanged 选项和git help config 中的config.ignoreStat 部分，了解有关它们如何工作的更多信息。

  使用这些意味着您需要明确指定诸如git diff 和git add 之类的命令的路径，即诸如git diff、git commit -a 之类的命令将不起作用。

• 更改您的操作系统和/或文件系统。根据 Git 手册页（与上一个项目符号中的相同），Windows 的 lstat 很慢，CIFS 文件系统也是如此。我怀疑理想情况是 Linux 或其他 *nix 上的 ext3 或 ext4。

Answer 2

自 2013 年以来，您现在（2020 年）拥有一个专用的 git sparse-checkout，它可以帮助仅克隆 Git 存储库的相关子集。

不仅 git status 会更快，而且随着 Git 2.28（2020 年第三季度），“git status”学会了报告稀疏结帐的状态。

参见Elijah Newren (newren)@commit afda36d、commit 30b00f0（2020 年 6 月 21 日）和commit 051df3c（2020 年 6 月 18 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 0cc4dca，7 月 6 日2020)}

wt-status: 也显示稀疏结帐状态

^{签字人：Elijah Newren}

人们在 $dayjob 尝试稀疏结账的一些早期反馈是，稀疏结账有时会让人迷惑；用户可能会忘记他们有一个稀疏签出，然后想知道文件去了哪里。

以简单的行的形式向“git status”添加一些输出：

You are in a sparse checkout with 35% of files present.  

显然，确切的数字会根据索引中没有设置SKIP_WORKTREE 位的文件百分比而变化。

---

注意：bash 提示脚本（在 contrib/ 中）在“set -u”下不起作用，已在 Git 2.32（2021 年第二季度）中修复。

参见Elijah Newren (newren) 的commit 5c0cbdb（2021 年 5 月 13 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 02112fc，2021 年 5 月 20 日）}

git-prompt：在set -u下工作

^{签字人：Elijah Newren}

Commit afda36d ("git-prompt: include sparsity state as well", 2020-06-21, Git v2.28.0-rc0 -- merge 列于batch #7) 添加了一些变量的使用控制如何在 git 提示符中显示稀疏状态，但隐式假设未定义的变量将被视为空字符串。

这会破坏在“set -u”下运行的用户；修复代码更明确。