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

Question

我将大约200 MB的代码推入回购。这花费了很多时间。反正我们可以显示进度条，以便我可以知道有多少代码被推入回购中吗？

Answer 1

这不是一个进度“栏”，但是git push在从终端运行时已默认报告进度。来自official Linux kernel git documentation for git push：

--progress

     

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

您尝试一次推送200 MB这一事实表明您可能会使用git做一些次优的事情。

Answer 2

使用Git 2.10（2016年第3季度）

，

git push --progress会更准确

请参阅Jeff King（peff）的commit e376f17

  

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

     

  
• 一个用于＆＃34;接收对象＆＃34;和
  
• 一个用于＆＃34;解决增量＆＃34;。
  

     

默认情况下，或两者都没有＆＃34; -v＆＃34;。

     

但是对于推送接收包，我们只需要＆＃34; resolving deltas＆＃34;阶段，不＆＃34; receiving objects＆＃34;进展。
  这有两个原因：

     

  

• 一个简单就是现有的客户已经在打印＆＃34;写对象＆＃34;同时进步。
    可以说＆＃34;接收＆＃34;从远端来看更有用，因为它告诉你实际上到底有什么，而不是可能卡在客户端和服务器之间的缓冲区中。但这需要协议扩展来告诉客户不要打印他们的进度。可能，但是   复杂性微不足道。

  

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

  

     

所以我们最好的选择是避免写任何不是的东西   在我们收到完整包之前，我们已经确定了一小部分。

2016年9月更新：Git 2.10就在那里，您可以在GitHub博客文章中看到这个进度表的示例＆＃34; Git 2.10 has been released＆＃34;：

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

现在，传入＆＃34; git push＆＃34;现在可以尝试推送太多字节 通过在接收时设置新的配置变量来拒绝 端。

commit c08db5a见commit 411481b，Jeff King (peff)（2016年8月24日） 请commit 5ad2186查看Christian Couder (chriscool)（2016年8月24日） ^{（Junio C Hamano -- gitster --于2016年9月9日commit da3b6f0合并）}

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

  

Receive-pack将其输入提供给index-pack或unpack-objects，这将很乐意接受发送者愿意提供的字节数。
  让我们允许一个任意的截止点，我们将停止将字节写入磁盘。

git config doc现在包括：

receive.maxInputSize

  

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

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

commit 545dc34见commit 9f1fd84，commit d53ba84（2019年4月12日）和commit 9219d12，SZEDER Gábor (szeder)（2019年4月5日）{。{3}}。 ^{（Junio C Hamano -- gitster --合并于commit 425e51e，2019年4月25日）}

commit 1aed1a5见SZEDER Gábor (szeder)（2019年5月19日） ^{（Junio C Hamano -- gitster --合并于commit fa03d9c，2019年5月30日）}

  

progress：打破太长的进度条线

     

最近增加的一些进度指标有很长的标题，   当翻译成某些语言时，它可能会更长   它们在更大的存储库上运行时显示，然后是   进度条的长度超过默认的80列终端宽度。

     

当进度条超过终端的宽度时   换行后，最后的CR不会返回到   进度条的开头，但是到最后一列的第一列   行。
  因此，先前显示的进展的第一行   bar不会被下一个覆盖，我们最终得到了一堆   滚动过去的截断进度条线：

$ 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.