git push --progress will be more accurate with Git 2.10 (Q3 2016)
Watch the e376f17 commit by Jeff King (peff)
The index-pack command has two progress indicators:
- one for "getting objects" and
- one for "delta resolution".
You do not get either the default, or both with " -v ".
But for pushing the receive packet we would like only the " resolving deltas " stage, and not the " receiving objects ".
There are two reasons for this:
One of them is that existing clients are already printing the "write objects" process at the same time.
Perhaps “receiving” from the far end is more useful because it tells you what actually got there, unlike what might hang in a buffer somewhere between the client and the server. But this will require an extension of the protocol so that clients do not print their progress. Perhaps, but complexity for a small gain.
The second reason is much more important.
In a full duplex connection, such as git-over-ssh, we can print the progress until the packet arrives and it immediately reaches the client.
But for a half duplex connection like git-over-http, we don’t have to say anything until we get the full request.
Everything we write can get stuck in the buffer by the web server. Worse, we might be stumped if this buffer fills up.
Therefore, it is best not to write anything that is not a small fixed size until we get the full package .
Update September 2016: Git 2.10 is already there, and you can see an example of this progress indicator in a GitHub blog post “ Git 2.10 released ”:
Git 2.11 Update (Q4 2016)
Now the incoming " git push " that tries to push too many bytes can now be rejected by setting a new configuration variable at the receiving end.
See commit c08db5a , commit 411481b (August 24, 2016) by Jeff King ( peff ) .
See commit 5ad2186 (August 24, 2016) by Christian Kuder ( chriscool ) .
(Merged by Junio C Hamano - [TG48] - in commit da3b6f0 , 09 Sep 2016)
receive-pack: allow specifying maximum input size
Receive-pack directs its input to index-pack or unpack-objects, which will happily accept as many bytes as the sender wants to provide.
Let me enable an arbitrary clipping point, where we stop writing bytes to disk.
git config doc now includes:
receive.maxInputSize
If the size of the incoming packet stream is greater than this limit, git-receive-pack will throw an error instead of accepting the package file.
If the value is not set or equal to 0, the size is not limited.
With Git 2.22, progress is better managed:
See commit 545dc34 , commit 9f1fd84 (April 12, 2019) and commit d53ba84 , commit 9219d12 (Apr 05, 2019) SEDER Gabor ( szeder ) .
(Merged by Junio C Hamano - [TG411] - in commit 425e51e , 25 Apr 2019)
See the 1aed1a5 (May 19, 2019) commit from SZEDER Gábor ( szeder ) .
(Merged by Junio C Hamano - [TG413] - in commit fa03d9c , 30 May 2019)
progress : break progress bar lines too long
Some of the recently added progress indicators have fairly long names, which can be even more when translated into some languages, and when they are displayed when working with large repositories, then the progress indicator increases longer than the default terminal width of 80 columns.
When the progress bar exceeds the width of the terminal, it gets wrapped in a string, and after that CR at the end does not return to the beginning of the progress bar, but until the first column of its last line.
Therefore, the first line of the previously shown progress, the next line is not overwritten, and we get a bunch of truncated progress 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 the progress bars after the header to exceed the width of the terminal, so the counter and optional percentage and bandwidth, i.e. all changing parts are on the last line.
Subsequent updates will only update part changes, but not the name, 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 a rebase display of progress:
See commit 5b12e31 , commit cd1096b , commit 077b979 , commit c9749b3 (June 24, 2019) and commit d7d9088 (June 27, 2019) SEDER Gabor ( szeder ) .
(Merged by Junio C Hamano - [TG418] - in commit 6624e07 , 09 Jul 2019)
rebase : fix distorted progress display with " -x "
When executing a command with the exec instruction during an interactive rebase session or for a git rebase -x range using git rebase -x , the output may be slightly distorted when the command name 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 becomes more distorted with an increase in the range of commits:
$ 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.
These extra digits and ' ) ' are the remnants of the previously displayed " Rebasing (N/M) " progress lines, which are usually completely overwritten by the lines " Executing: <cmd> " unless cmd 'is short and the " N/M " part is long .
Make sure that the previously displayed " Rebasing (N/M) " line is cleared using the term_clear_line() helper function added in the previous patch.
Do this only when you are not " --verbose ", because in this case these " Rebasing (N/M) " lines are not printed as a progress (ie, as lines with " \r " at the end), but as "normal" output (with ' \n ' at the end).
Several other rebase commands display similar messages, for example, " Stopped at <abbrev-oid>... <subject> " for the commands " edit " or " break " or " Successfully rebased and updated <full-ref>. " At the very end .
They are so long that they almost always overwrite this “ Rebasing (N/M) ” progress line, but let's be careful and clear the last line before printing them either.
In " t3420-rebase-autostash.sh ", two helper functions prepare the expected result of four tests that check the complete output of ' git rebase ' and thus affect this change, so adjust their expectations to allow for clearing a new line.
Please note that this patch does not completely preclude the possibility of similarly distorted results, for example, some error messages from rebase or the message “ Auto-merging <file> ” from the merge depth of the technique may not be long enough to completely cover the last “ Rebasing (N/M) . "
This patch does nothing with them, because working separately with them will lead to too much outflow, while a common call to term_clear_line() in the general code path of pick_commits() would hide the " Rebasing (N/M) " line too early , and it will either flicker or be invisible.
However, Git 2.24 (Q4 2019) contains a regression fix to output progress
See commit 2bb74b5 , commit bbf4756 (September 16, 2019) by SZEDER Gábor ( szeder ) .
(Merged by Junio C Hamano - [TG450] - in commit ef93bfb , 07 Oct 2019)
Check progress display
' progress.c ' has seen a few fixes recently ( commit 545dc34 and commit 9f1fd84 , both v2.22.0-rc0), and, unfortunately, some of those fixes required further fixes ( commit 1aed1a5 ).
The progress display, however, is critically dependent on synchronization because it is updated only once per second or, if the total is known in advance, every 1%, and there is also bandwidth. These make progress display too uncertain for testing as is.
Hence:
progress : avoid an empty line when breaking a progress line
Since commit 545dc34 ( progress : break lines of the progress bar too long, 2019-04-12, Git v2.22.0-rc0) when breaking a line of progress that is too long, sometimes it looks as if an extra empty line was added between the header line and the counters line.
To make sure that the previously displayed progress bar is completely closed when writing a new, shorter title bar, we calculate how many characters need to be rewritten with spaces.
Alas, this calculation does not take into account the line feed character at the end of a new header line, as a result of which another space was printed than is strictly necessary.
This extra space does not matter if the length of the previous progress line was shorter than the width of the terminal.
However, if the previous line corresponded to the width of the terminal, then this extra space lengthened the new line, effectively adding this empty line after the title bar.
Correct this one at a time to avoid this false blank line.