git push --progress will be more precise with Git 2.10 (Q3 2016)
See commit e376f17 from Jeff King (peff)
The index-pack command has two progress meters:
- one for "receiving objects", and
- one for "resolving deltas".
You get neither by default, or both with "-v".
But for a push through receive-pack, we would want only the "resolving deltas" phase, not the "receiving objects" progress.
There are two reasons for this:
One is simply that existing clients are already printing "writing objects" progress at the same time.
Arguably "receiving" from the far end is more useful, because it tells you what has actually gotten there, as opposed to what might be stuck in a buffer somewhere between the client and server. But that would require a protocol extension to tell clients not to print their progress. Possible, but
complexity for little gain.
The second reason is much more important.
In a full-duplex connection like git-over-ssh, we can print progress while
the pack is incoming, and it will immediately get to the client.
But for a half-duplex connection like git-over-http, we should not say anything until we have received the full request.
Anything we write is subject to being stuck in a buffer by the webserver. Worse, we can end up in a deadlock if that buffer fills up.
So our best bet is to avoid writing anything that isn't a
small fixed size until we've received the full pack.
Update September 2016: Git 2.10 is there, and you can see an example of this progress meter at the GitHub blog post "Git 2.10 has been released":
Update Git 2.11 (Q4 2016)
Now, an incoming "git push" that attempts to push too many bytes can now
be rejected by setting a new configuration variable at the receiving
end.
See commit c08db5a, commit 411481b (24 Aug 2016) by Jeff King (peff).
See commit 5ad2186 (24 Aug 2016) by Christian Couder (chriscool).
(Merged by Junio C Hamano -- gitster -- in commit da3b6f0, 09 Sep 2016)
receive-pack: allow a maximum input size to be specified
Receive-pack feeds its input to either index-pack or unpack-objects, which will happily accept as many bytes as a sender is willing to provide.
Let's allow an arbitrary cutoff point where we will stop writing bytes to disk.
git config doc now includes:
receive.maxInputSize
If the size of the incoming pack stream is larger than this limit, then git-receive-pack will error out, instead of accepting the pack file.
If not set or set to 0, then the size is unlimited.
With Git 2.22, the progress is better managed:
See commit 545dc34, commit 9f1fd84 (12 Apr 2019), and commit d53ba84, commit 9219d12 (05 Apr 2019) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit 425e51e, 25 Apr 2019)
See commit 1aed1a5 (19 May 2019) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit fa03d9c, 30 May 2019)
progress: break too long progress bar lines
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 (Q3 2019) fixes the progress display of a rebase:
See commit 5b12e31, commit cd1096b, commit 077b979, commit c9749b3 (24 Jun 2019), and commit d7d9088 (27 Jun 2019) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit 6624e07, 09 Jul 2019)
rebase: fix garbled progress display with '-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 '
' at the end), but as "regular" output (with '
' 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
