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 存储库中的 track 子文件夹（例如trunk/project-a 、 branches/*/project-a 、 tags/*/project-a ，...）而不是整个存储库。 如果这对您的存储库有意义，则意味着您可以有更小的结帐和更快的git status运行。

• 查看git help read-tree的 Sparse Checkout 部分。 这将告诉您如何设置 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 &c 这样的命令将不起作用。

• 更改您的操作系统和/或文件系统。 根据 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 日）和051df3c （2020 年 6 月 18 日） 。
^{（由Junio C gitster合并gitster 提交 0cc4dca ，2020 年 7 月 6 日）}

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 gitster合并-- gitster -- in 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 -- 合并在第 7 批中列出) 添加了一些变量的使用来控制如何在git 提示，但隐含地假设未定义的变量将被视为空字符串。

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