logo标签列表

我该如何知道git push上传进度的百分比？

gitgithubgit-push
17

我正在将大约200 MB的代码推送到一个仓库中。这需要很长时间。有没有办法显示进度条，以便我可以知道有多少代码已经被推送到了仓库中？

4
推送200mb的可能意味着你正在使用Git处理一些不应处理的东西。 - Daenyth
1
你所说的“大约200 MB的代码”具体指什么？你是否有一个大小为200 MB的文件？或者你推送的提交中所有更改的总和实际上等于200 MB？ - user456814
1
@Daenyth，有时候你需要推送整个代码库是完全合理的——例如当将现有存储库迁移到新的Git托管系统（如Github、Bitbucket、VSTS等）时。这种情况很常见。 - Ivan
1
@Daenyth，作为一名开发人员 - 是的，不太频繁，但作为DevOps \ CD专家，我比实际提交更多地做到了这一点 :) 所以，请保持开放的心态！ - Ivan
3
问题的目的不是要闭门造车并假设OP试图做什么 - 他正在寻求一个可回答的问题的答案。最好保持话题相关。 - dylanh724
我不知道为什么，但是 git push -u origin master 就成功了... - Gabriel Pellegrino
2个回答
11

git push --progress 在 Git 2.10 (2016 年第三季度) 会更加精确。

参见 Jeff King (peff) 的 commit e376f17。

index-pack 命令有两个进度指示器：

  • 一个是“接收对象”的，
  • 另一个是“解决差异”的。

默认情况下不会显示任何进度，添加 "-v" 后会同时显示两者的进度。

但对于通过 receive-pack 推送的内容，我们只需要“解决差异”阶段的进度，而不需要“接收对象”的进度。
原因有两个：

  • 一是现有客户端已经同时打印“写入对象”进度。
    可以说从远端“接收”更有用，因为它告诉您实际到达的内容，而不仅仅是可能被卡在客户端和服务器之间的缓冲区中的内容。 但这将需要协议扩展，以告诉客户端不要打印进度。 可能性存在，但增加了复杂性，收益微不足道。

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

因此，我们最好是在完全接收 pack 之前避免写入任何不是小固定大小的内容。

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

https://cloud.githubusercontent.com/assets/3477155/18064845/34bb6956-6dff-11e6-8e3e-8a92c0bddaef.gif

更新 Git 2.11 (2016年第四季度)

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

查看 提交 c08db5a, 提交 411481b (2016年8月24日) 由Jeff King (peff)完成。
查看 提交 5ad2186 (2016年8月24日) 由Christian Couder (chriscool)完成。
(在提交da3b6f0中由Junio C Hamano -- gitster --合并，日期为2016年9月9日)

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

Receive-pack将其输入提供给index-pack或unpack-objects，这两个程序会愉快地接受发送方提供的任意字节数。
让我们允许设置一个任意的截止点，在此处停止向磁盘写入字节。

git config doc 现在包括：

receive.maxInputSize

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

使用Git 2.22，进度得到更好地管理：

请看提交记录 545dc34，提交记录 9f1fd84（2019年4月12日），以及提交记录 d53ba84，提交记录 9219d12（2019年4月5日），作者是SZEDER Gábor (szeder)。
（由Junio C Hamano -- gitster --在提交记录 425e51e中合并，于2019年4月25日）

查看提交记录1aed1a5（2019年5月19日）由SZEDER Gábor (szeder)进行。
（由Junio C Hamano -- gitster --于2019年5月30日合并至提交记录fa03d9c）

progress：分割过长的进度条行

Some of the recently added progress indicators have quite long titles, which might be even longer when translated to some languages, and when they are shown while operating on bigger repositories, then the progress bar grows longer than the default 80 column terminal width.

When the progress bar exceeds the width of the terminal it gets line-wrapped, and after that the CR at the end doesn't return to the beginning of the progress bar, but to the first column of its last line.
Consequently, the first line of the previously shown progress bar is not overwritten by the next, and we end up with a bunch of truncated progress bar lines scrolling past:

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

Prevent this by breaking progress bars after the title once they exceed the width of the terminal, so the counter and optional percentage and throughput, i.e. all changing parts, are on the last line.
Subsequent updates will from then on only refresh the changing parts, but not the title, and it will look like this:

$ 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进程显示的问题。

请查看提交 5b12e31, 提交 cd1096b, 提交 077b979, 提交 c9749b3 (2019年6月24日)，以及提交 d7d9088 (2019年6月27日)，作者为SZEDER Gábor (szeder)。
(由Junio C Hamano -- gitster --于提交 6624e07合并，日期为2019年7月9日)

rebase: 修复使用 '-x' 时混乱的进度显示

When running a command with the 'exec' instruction during an interactive rebase session, or for a range of commits using 'git rebase -x', the output can be a bit garbled when the name of the command is short enough:

 $ git rebase -x true HEAD~5
 Executing: true
 Executing: true
 Executing: true
 Executing: true
 Executing: true)
 Successfully rebased and updated refs/heads/master.

Note the ')' at the end of the last line.
It gets more garbled as the range of commits increases:

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

Those extra numbers and ')' are remnants of the previously displayed "Rebasing (N/M)" progress lines that are usually completely overwritten by the "Executing: <cmd>" lines, unless 'cmd' is short and the "N/M" part is long.

Make sure that the previously displayed "Rebasing (N/M)" line is cleared by using the term_clear_line() helper function added in the previous patch.
Do so only when not being '--verbose', because in that case these "Rebasing (N/M)" lines are not printed as progress (i.e. as lines with '\r' at the end), but as "regular" output (with '\n' at the end).

A couple of other rebase commands print similar messages, e.g. "Stopped at <abbrev-oid>... <subject>" for the 'edit' or 'break' commands, or the "Successfully rebased and updated <full-ref>." at the very end.

These are so long that they practically always overwrite that "Rebasing (N/M)" progress line, but let's be prudent, and clear the last line before printing these, too.

In 't3420-rebase-autostash.sh', two helper functions prepare the expected output of four tests that check the full output of 'git rebase' and thus are affected by this change, so adjust their expectations to account for the new line clearing.

Note that this patch doesn't completely eliminate the possibility of similar garbled outputs, e.g. some error messages from rebase or the "Auto-merging <file>" message from within the depths of the merge machinery might not be long enough to completely cover the last "Rebasing (N/M)" line.

This patch doesn't do anything about them, because dealing with them individually would result in way too much churn, while having a catch-all term_clear_line() call in the common code path of pick_commits() would hide the "Rebasing (N/M)" line way too soon, and it would either flicker or be invisible.

然而，Git 2.24（2019年第四季度）包括一个进度输出回归修复。
请参见提交记录2bb74b5，提交记录bbf4756（由SZEDER Gábor (szeder)于2019年9月16日提交）。
（由Junio C Hamano -- gitster --合并于提交记录ef93bfb，2019年10月7日）

测试进度显示

'progress.c'最近进行了一些修复（commit 545dc34和commit 9f1fd84，均为v2.22.0-rc0版本），但不幸的是，其中一些修复需要进一步修复（commit 1aed1a5）。
然而，进度显示严重依赖于时间，因为它只在每秒更新一次，或者如果总量事先已知，则每1％更新一次，并且还有吞吐率。这使得原样测试的进度显示过于不确定。
因此：

progress: 避免在分割进度行时出现空行

自从提交 545dc34（progress: break too long progress bar lines, 2019-04-12, Git v2.22.0-rc0）以来，当分割过长的进度行时，有时会看起来像在标题行和计数器之间添加了多余的空行。 为确保在编写新的、更短的标题行时完全覆盖先前显示的进度行，我们计算需要用空格覆盖多少个字符。 然而，这个计算没有考虑到新标题行末尾的换行符，导致打印了一个比严格必要的多一个空格。 如果以前的进度行长度小于终端宽度，则这个额外的空格字符无关紧要。 但是，如果前一行与终端宽度匹配，则此额外的空格使新行变长，实际上在标题行后添加了那个空行。 修复这个一位偏差，避免出现虚假的空行。
在 Git 2.25（2020年第一季度），在生成提交图时，一种进度消息总是会给出，而不是遵循“如果需要超过两秒钟，则显示进度”的模式，这已得到纠正。

请看提交ecc0869，提交44a4693 (2019年11月25日) 由Derrick Stolee (derrickstolee)完成。
(由Junio C Hamano -- gitster --合并到提交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文档现在包括以下内容：

GIT_PROGRESS_DELAY:

一个数字，控制显示可选进度指示器之前的延迟时间（以秒为单位）。
默认为2。

使用Git 2.28（2020年第三季度），提交图可以显示查找可到达提交的进度。

请查看由Taylor Blau (ttaylorr)于2020年5月13日提交的2f00c35号提交, 1f1304d号提交, 0ec2d0f号提交, 5b6653e号提交, 630cd51号提交, d335ce8号提交，以及2020年5月18日的fa8953c号提交和2020年5月5日的1fe1084号提交。
(在dc57a9b号提交中由Junio C Hamano -- gitster --合并，时间为2020年6月9日)

commit-graph.c: 显示找到可达提交的进度

由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' 在慢速情况下看起来像是闲置的，并且同时提供一些输出，请添加进度条。
一般来说，我们不希望出现进度条，因为使用 'packed-refs' 文件剥离引用很快。
如果很慢并且我们确实显示了进度条，则随后的 'fill_oids_from_commits()' 将很快，因为所有对 'lookup_commit_reference_gently()' 的调用都将是 no-op。
两个进度条都被延迟了，所以不太可能会出现多个进度条。在任何情况下，这种中间状态都将在少数补丁中消失，此时最多只会出现一个进度条。

在 Git 2.28（2020 年第三季度）中，"git commit-graph --write" 命令生成进度输出的代码存在一些故障，在同一版本的 2.28 中已经修复。

查看提交150cd3b，提交6f9d5f2（于2020年7月9日），作者为SZEDER Gábor（szeder）。
（由Junio C Hamano -- gitster --于2020年7月15日合并在提交12f5eb9中）

commit-graph: 修复可达提交的进度

签名：SZEDER Gábor

To display a progress line while iterating over all refs, d335ce8f24 ("commit-graph.c: show progress of finding reachable commits", 2020-05-13, Git v2.28.0-rc0 -- merge listed in batch #2) should have added a pair of start_delayed_progress() and stop_progress() calls around a for_each_ref() invocation.

Alas, the stop_progress() call ended up at the wrong place, after write_commit_graph(), which does all the commit-graph computation and writing, and has several progress lines of its own.

Consequently, that new

Collecting referenced commits: 123

progress line is overwritten by the first progress line shown by write_commit_graph(), and its final "done" line is shown last, after everything is finished:

Expanding reachable commits in commit graph: 344786, done.
Computing commit changed paths Bloom filters: 100% (344786/344786), done.
Collecting referenced commits: 154, done.

Move that stop_progress() call to the right place.

While at it, drop the unnecessary 'if (data.progress)' condition protecting the stop_progress() call, because that function is prepared to handle a NULL progress struct.

请查看提交 862aead（2020年7月10日）由SZEDER Gábor (szeder)提交。
（由Junio C Hamano -- gitster --在提交d1ae8ba中合并，2020年7月15日）

commit-graph：修复“从输入中收集提交”的进度行

签名作者：SZEDER Gábor
审阅者：Derrick Stolee

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接