我怎么知道git push的百分比是多少？

我正在将一个大约200 MB的代码推送到一个回购中.这花费了很多时间.无论如何我们可以显示进度条,以便我可以知道有多少代码被推入回购中？

git push --progress Git 2.10（2016年第三季度）将更加精确

参见Jeff King的commit e376f17（peff）

该index-pack命令有两个进度表：

一个用于“接收对象”，以及

一种用于“解决三角洲”问题。

默认情况下，您都不会获得“或-v”。

但对于通过接收包一推，我们希望只有“ resolving deltas”阶段，没有了“ receiving objects”的进展。
有两个原因：

一个简单的问题是现有客户已经在同时打印“书写对象”进度。
可以说，从远端“接收”更为有用，因为它告诉您实际到达那里的内容，而不是客户端和服务器之间的缓冲区中可能停留的内容。但这需要协议扩展，以告知客户端不要打印其进度。可能，但是复杂但收效甚微。

第二个原因更为重要。
在像git-over-ssh这样的全双工连接中，我们可以在传入包时打印进度，它会立即到达客户端。
但是对于像git-over-http这样的半双工连接，在收到完整请求之前，我们不应该说什么。
我们编写的任何内容都将被Web服务器卡在缓冲区中。更糟糕的是，如果该缓冲区已满，我们可能会陷入僵局。

所以我们最好的办法是避免收到固定大小的东西，直到我们收到完整的包装。

2016年9月更新：Git 2.10已经存在，您可以在GitHub博客文章“ Git 2.10已发布 ”中看到此进度表的示例：

更新Git 2.11（2016年第四季度）

现在，git push现在可以通过在接收端设置新的配置变量来拒绝试图推送太多字节的传入“ ”。

参见Jeff King（）的commit c08db5a和411481b（2016年8月24日）。 参见Christian Couder（）提交5ad2186（2016年8月24日）。^{（由Junio C Hamano合并--在commit da3b6f0中，2016年9月9日）}peff
chriscool
gitster

receive-pack：允许指定最大输入大小

Receive-pack将其输入馈给index-pack或unpack-object，它们将愉快地接受发送者愿意提供的尽可能多的字节。
让我们允许一个任意的截止点，在此我们将停止将字节写入磁盘。

git config doc现在包括：

receive.maxInputSize

如果传入的包流的大小大于此限制，则git-receive-pack将出错，而不是接受包文件。
如果未设置或设置为0，则大小不受限制。

使用Git 2.22，可以更好地管理进度：

见提交545dc34，提交9f1fd84（2019年4月12日），以及提交d53ba84，提交9219d12（2019年4月5日）由SZEDER伽柏（szeder）。
^{（通过合并JUNIOÇ滨野- gitster-在提交425e51e，2019年4月25日）}

见提交1aed1a5（2019年5月19日）由SZEDER的Gabor（ ）szeder。
^{（通过合并JUNIOÇ滨野- gitster-在提交fa03d9c，2019 5月30日）}

progress：中断太长的进度条行

最近添加的某些进度指示器中的标题非常长，当翻译成某些语言时，标题可能会更长，并且当它们在较大的存储库上运行时显示时，进度条的长度会超过默认的80列终端宽度。

当进度条超过终端的宽度时，它会被换行，然后，末尾的CR不会返回到进度条的开始，而是返回到最后一行的第一列。
因此，先前显示的进度条的第一行不会被下一行覆盖，我们最终会看到一堆截断的进度条行，它们滚动通过：

$ 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（Q3 2019）修复了变基进度显示：

见提交5b12e31，提交cd1096b，提交077b979，提交c9749b3（2019年6月24日），并提交d7d9088由（2019年6月27日）SZEDER伽柏（szeder）。
^{（由Junio C gitsterHamano合并--在commit 6624e07中，2019年7月9日）}

rebase：用“ -x” 修复乱码显示

在exec交互式rebase会话中使用“ ”指令运行命令时，或使用“ 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'短而“ N/M”部分长。

确保Rebasing (N/M)使用term_clear_line()先前补丁中添加的辅助功能清除了先前显示的“ ”行。
仅当不是' --verbose' 时才这样做，因为在这种情况下，这些“ Rebasing (N/M)”行不会作为进度打印（即，以' \r'结尾的行），而是作为“常规”输出（以' \n'结尾的行）打印。

几个其他的rebase命令会打印类似的消息，例如Stopped at ... ，对于' edit'或' break'命令，使用“ Successfully rebased and updated .” 或在末尾使用“ ”。

这些时间太长，以至于实际上它们总是会覆盖该Rebasing (N/M)进度行，但是我们要谨慎一些，在打印这些行之前也要清除最后一行。

在' t3420-rebase-autostash.sh'中，两个帮助器函数准备了四个测试的预期输出，这些测试检查了' git rebase' 的全部输出，因此受此更改的影响，因此请调整其预期以解决新的行清除问题。

请注意，此修补程序并不能完全消除出现类似乱码的可能性，例如，来自rebase的某些错误消息或Auto-merging 来自合并机制深度内的“ ”消息可能不足以完全覆盖最后的“ Rebasing (N/M)”行。

这个补丁对它们没有任何作用，因为单独处理它们会导致过多的用户流失，而term_clear_line()在的通用代码路径中进行全面调用pick_commits()会Rebasing (N/M)过早地隐藏“ ”行，或者闪烁或看不见。

但是，Git 2.24（2019年第四季度）包括针对进度输出的回归修复

见提交2bb74b5，提交bbf4756（2019年9月16日）由SZEDER伽柏（szeder）。
^{（由Junio C gitsterHamano合并--在ef93bfb提交中，2019年10月7日）}

测试进度显示

' progress.c'最近已经看到了一些修复程序（提交545dc34和9f1fd84 提交，都v2.22.0-rc0），不幸的是，其中一些修复需要进一步的修复（提交1aed1a5）。

但是，进度显示严格取决于时间，因为它仅每秒更新一次，或者，如果预先知道总数，则每1％更新一次，并且还具有吞吐率。这些使进度显示对于按原样测试而言过于不确定。

因此：

progress：在断开进度线时避免空行

由于在拆分太长的进度行时提交了545dc34（progress：打破了太长的进度条行，2019-04-12，Git v2.22.0-rc0），因此有时似乎在标题行和标题行之间添加了多余的空行柜台。

为了确保在编写新的较短标题行时完全覆盖了先前显示的进度行，我们计算需要用空格覆盖多少个字符。
A，此计算并未考虑新标题行末尾的换行符，从而导致打印超出严格要求的空间。
如果前一个进度线的长度小于终端的宽度，则多余的空格字符无关紧要。
但是，如果前一行与终端宽度匹配，则此额外空间会使新行变长，从而在标题行之后有效地添加该空行。

将此问题一一解决，以免出现虚假的空行。

它不是一个进度"栏",但是git push当它从终端运行时已经默认报告进度.从官方Linux内核git文档git push:

--progress

除非-q已指定,否则在连接到终端时,默认情况下会在标准错误流上报告进度状态.即使标准错误流未定向到终端,此标志也会强制进度状态.

你试图一次推200 MB的事实表明你可能会用git做一些次优的事情.