git push --progress 将在 Git 2.10（2016 年第三季度）中更加精确
请参阅 Jeff King (peff) 的 commit e376f17
index-pack 命令有两个进度条：
- 一个用于“接收对象”，并且
- 一个用于“解决增量”。
默认情况下，您既不会获得，也不会同时获得“-v”。
但对于通过接收包的推送，我们只需要“resolving deltas”阶段，而不是“receiving objects”进度。
这有两个原因：
-
一个很简单，现有客户端已经在同时打印“写入对象”进度。
可以说，从远端“接收”更有用，因为它告诉您实际到达那里的内容，而不是可能卡在客户端和服务器之间某处的缓冲区中的内容。但这需要一个协议扩展来告诉客户不要打印他们的进度。可能，但是
复杂而无益。
-
第二个原因更为重要。
在像 git-over-ssh 这样的全双工连接中，我们可以在打印进度的同时
包裹收到了，它会立即到达客户端。
但是对于像 git-over-http 这样的半双工连接，在我们收到完整的请求之前，我们不应该说什么。
我们编写的任何内容都会被网络服务器卡在缓冲区中。更糟糕的是，如果缓冲区填满，我们可能会陷入死锁。
所以我们最好的办法是避免写任何不是
小固定尺寸，直到我们收到完整的包装。
2016 年 9 月更新：Git 2.10 已经发布，您可以在 GitHub 博客文章“Git 2.10 has been released”中查看此进度表的示例：
更新 Git 2.11（2016 年第四季度）
现在，尝试推送过多字节的传入“git push”现在可以
通过在接收端设置一个新的配置变量来拒绝
结束。
见commit c08db5a、commit 411481b（2016 年 8 月 24 日）Jeff King (peff)。
请参阅 Christian Couder (chriscool) 的 commit 5ad2186（2016 年 8 月 24 日）。
（由 Junio C Hamano -- gitster -- 合并于 commit da3b6f0，2016 年 9 月 9 日）
receive-pack: 允许指定最大输入大小
Receive-pack 将其输入提供给 index-pack 或 unpack-objects，它们会很乐意接受发送者愿意提供的字节数。
让我们允许一个任意的截止点，我们将停止将字节写入磁盘。
git config doc 现在包括：
receive.maxInputSize
如果传入包流的大小大于此限制，则 git-receive-pack 将出错，而不是接受包文件。
如果不设置或设置为0，则大小无限制。
使用 Git 2.22，可以更好地管理进度：
参见SZEDER Gábor (szeder)@commit 545dc34、commit 9f1fd84（2019 年 4 月 12 日）和commit d53ba84、commit 9219d12（2019 年 4 月 5 日）。
（由@987654338 中的Junio C Hamano -- gitster -- 合并@，2019 年 4 月 25 日）
参见 SZEDER Gábor (szeder) 的 commit 1aed1a5（2019 年 5 月 19 日）。
（由 Junio C Hamano -- gitster -- 合并到 commit fa03d9c，2019 年 5 月 30 日）
progress: 进度条断线过长
最近添加的一些进度指示器的标题很长，
当翻译成某些语言时，这可能会更长，当
它们在更大的存储库上运行时显示，然后
进度条的长度超过了默认的 80 列终端宽度。
当进度条超过终端的宽度时
换行，然后最后的 CR 不会返回到
进度条的开头，但到最后一列的第一列
线。
因此，前面显示的进度的第一行
bar 不会被 next 覆盖，我们最终会得到一堆
滚动过去的截断进度条线：
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
通过打破标题后的进度条来防止这种情况
超过终端的宽度，所以计数器和可选
百分比和吞吐量，即所有变化的部件，都在最后
线。
以后的更新将从此只刷新变化
部分，但不是标题，它看起来像这样：
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Git 2.23（2019 年第三季度）修复了 rebase 的进度显示：
参见commit 5b12e31、commit cd1096b、commit 077b979、commit c9749b3（2019 年 6 月 24 日）和 commit d7d9088（2019 年 6 月 27 日）SZEDER Gábor (szeder)。
（由 @987654349 合并@in commit 6624e07，2019 年 7 月 9 日）
rebase: 用'-x'修复乱码进度显示
在交互式变基会话期间使用“exec”指令运行命令时，或使用“git rebase -x”执行一系列提交时，当命令名称足够短时，输出可能会有点乱码：
$ git rebase -x true HEAD~5
Executing: true
Executing: true
Executing: true
Executing: true
Executing: true)
Successfully rebased and updated refs/heads/master.
注意最后一行末尾的“)”。
随着提交范围的增加，它变得更加乱码：
$ git rebase -x true HEAD~50
Executing: true)
[ repeated 3 more times ]
Executing: true0)
[ repeated 44 more times ]
Executing: true00)
Successfully rebased and updated refs/heads/master.
那些额外的数字和“)”是先前显示的“Rebasing (N/M)”进度线的残余，通常被“Executing: <cmd>”行完全覆盖，除非“cmd”很短并且“ N/M" 部分很长。
确保使用上一个补丁中添加的term_clear_line() 辅助函数清除先前显示的“Rebasing (N/M)”行。
仅在不是“--verbose”时才这样做，因为在这种情况下，这些“Rebasing (N/M)”行不会打印为进度（即，末尾带有“\r”的行），而是“常规”输出（以“\n”结尾）。
其他一些变基命令会打印类似的消息，例如“Stopped at <abbrev-oid>... <subject>”用于“edit”或“break”命令，或“Successfully rebased and updated <full-ref>.”在最后。
它们太长了，几乎总是覆盖“Rebasing (N/M)”进度线，但我们要谨慎，在打印这些之前清除最后一行。
在“t3420-rebase-autostash.sh”中，两个辅助函数准备
四个测试的预期输出检查了 'git rebase' 的完整输出，因此受到此更改的影响，因此调整他们的预期以考虑新的线路清除。
请注意，此补丁并不能完全消除
类似的乱码输出，例如来自 rebase 的一些错误消息或
来自合并深处的“Auto-merging <file>”消息
机器可能不够长，无法完全覆盖最后
“Rebasing (N/M)”行。
这个补丁不会对它们做任何事情，因为单独处理它们会导致太多的流失，而在pick_commits() 的公共代码路径中使用包罗万象的term_clear_line() 调用会隐藏“@ 987654446@" 线太快了，它会闪烁或不可见。
但是，Git 2.24（2019 年第四季度）包含进度输出的回归修复
参见commit 2bb74b5、commit bbf4756（2019 年 9 月 16 日）SZEDER Gábor (szeder)。
（由 Junio C Hamano -- gitster -- 合并到 commit ef93bfb，2019 年 10 月 7 日）
测试进度显示
'progress.c' 最近看到了一些修复（commit 545dc34 和 commit 9f1fd84，都是 v2.22.0-rc0），不幸的是，
其中一些修复需要进一步修复 (commit 1aed1a5)。
但是，进度显示严重依赖于时间，因为它每秒只更新一次，或者如果事先知道总数，则每 1% 更新一次，而且还有吞吐率。这些
使进度显示过于不确定，无法按原样进行测试。
因此：
progress: 打破进度线时避免空行
由于commit 545dc34 (progress: 中断太长的进度条行，
2019-04-12，Git v2.22.0-rc0) 分割过长的进度线时，有时会
看起来好像在标题行和计数器之间添加了一个多余的空行。
为确保在编写新的、较短的标题行时完全覆盖之前显示的进度行，我们计算需要用空格覆盖多少字符。
唉，这个计算没有考虑到末尾的换行符
新的标题行，导致打印的空间比严格必要的多一个。
如果上一个进度线的长度小于终端的宽度，则这个额外的空格字符无关紧要。
但是，如果前一行与终端宽度匹配，那么这个额外的空间会使新行变长，实际上是在标题行之后添加了空行。
逐一修复此问题，以避免出现虚假的空行。
使用 Git 2.25（2020 年第一季度），在提交图生成期间总是给出一种进度消息，而不是遵循“如果花费超过两秒，则显示进度”模式，已更正。
参见Derrick Stolee (derrickstolee) 的commit ecc0869、commit 44a4693（2019 年 11 月 25 日）。
（由 Junio C Hamano -- gitster -- 合并于 commit 41dac79，2019 年 12 月 10 日）
commit-graph：使用start_delayed_progress()
帮助者：Jeff King
报告者：ryenus
署名者：Derrick Stolee
在编写提交图时，我们会显示几个提交阶段的进度。当我们使用start_delayed_progress() 时，只有在该步骤需要相当长的时间时才会出现进度线。
但是，遗漏了一个地方：计算代数。这通常是一个非常快的操作，因为所有提交都已在上一步中解析。但是，无论添加多少提交，这都会显示给所有用户。
检查进度输出的测试已经更新为使用GIT_PROGRESS_DELAY=0 来强制实现预期输出。
那个新的环境变量来自：
progress：创建GIT_PROGRESS_DELAY
帮助：Jeff King
签字人：Derrick Stolee
start_delayed_progress() 方法是一种向用户显示可选进度的首选方法，因为它会忽略耗时不到两秒的步骤。
然而，这使得测试变得不可靠，因为测试预计会非常快。
此外，用户可能希望根据他们对终端噪音的偏好来减少或增加此时间间隔。
创建GIT_PROGRESS_DELAY 环境变量来控制start_delayed_progress() 期间设置的延迟。
在某些测试中设置值以保证它们的输出保持一致。
git documentation 现在包括：
GIT_PROGRESS_DELAY:
控制在显示可选进度指示器之前延迟多少秒的数字。
默认为 2。
使用 Git 2.28（2020 年第三季度），提交图可以显示查找可达提交的进度。
见commit 2f00c35、commit 1f1304d、commit 0ec2d0f、commit 5b6653e、commit 630cd51、commit d335ce8（2020 年 5 月 13 日）、commit fa8953c（2020 年 5 月 18 日）和@987620375@（20 年 5 月 5 日） ) by Taylor Blau (ttaylorr)。
（由 Junio C Hamano -- gitster -- 合并于 commit dc57a9b，2020 年 6 月 9 日）
签字人：Taylor Blau
当调用“git commit-graph write --reachable”时，提交图机制调用“for_each_ref()”来发现可访问的提交集。
现在，'add_ref_to_set' 回调除了将 OID 添加到已知可达的 OID 集外，没有做任何事情。在随后的提交中，“add_ref_to_set”将假定剥离引用。对于具有最新“$GIT_DIR/packed-refs”的存储库，此操作应该很快，但在一般情况下可能会很慢。
为了避免在慢速情况下“git commit-graph write”与“--reachable”处于空闲状态，请添加一个进度表以同时提供一些输出。
一般来说，我们根本不希望出现进度条，因为使用“packed-refs”文件剥离引用很快。
如果它很慢并且我们确实显示了进度表，那么随后的“fill_oids_from_commits()”将会很快，因为对“lookup_commit_reference_gently()”的所有调用都将是空操作。
两个进度条都有延迟，因此不太可能出现多个。在任何一种情况下，这个中间状态都会在少数补丁中消失，此时最多会有一个进度条。
在 Git 2.28（2020 年第三季度）中，从“git commit-graph --write”生成进度输出的代码有一些损坏，这些损坏已在同一个 2.28 版本中得到修复。
参见SZEDER Gábor (szeder) 的commit 150cd3b、commit 6f9d5f2（2020 年 7 月 9 日）。
（由 Junio C Hamano -- gitster -- 合并到 commit 12f5eb9，2020 年 7 月 15 日）
签字人：SZEDER Gábor
要在遍历所有 refs 时显示进度线，d335ce8f24 ("commit-graph.c: 显示查找可达提交的进度", 2020-05-13, Git v2.28.0-rc0 -- merge 列于batch #2) 应该在 for_each_ref() 调用周围添加一对 start_delayed_progress() 和 stop_progress() 调用。
唉，stop_progress() 调用在错误的地方结束了，在 write_commit_graph() 之后，它完成了所有的提交图计算和写入，并且有几个自己的进度线。
因此，新的
Collecting referenced commits: 123
进度线被write_commit_graph() 显示的第一条进度线覆盖，最后显示“完成”行，一切都完成后：
Expanding reachable commits in commit graph: 344786, done.
Computing commit changed paths Bloom filters: 100% (344786/344786), done.
Collecting referenced commits: 154, done.
将stop_progress() 呼叫移动到正确的位置。
同时，删除保护stop_progress() 调用的不必要的“if (data.progress)”条件，因为该函数已准备好处理NULL 进度结构。
在SZEDER Gábor (szeder)commit 862aead（2020 年 7 月 10 日）查看更多信息。
（由 Junio C Hamano -- gitster -- 合并到 commit d1ae8ba，2020 年 7 月 15 日）
签字人：SZEDER Gábor
审核人：Derrick Stolee