On Thu, Aug 22, 2019 at 10:20:08AM -0400, Charles Diza wrote:
> By 2.22.1 at the latest (and continuing into 2.23.0) there is a
> problem with the display of progress indication during `git pull`
> (and possibly other commands, I don't know).
>
> I'm on macOS, and this happens in both Terminal.app and iTerm2.app,
> on both macOS 10.13.6 and 10.14.6: In a standard 80-column wide
> terminal window, cd into a git repo and do `git pull`. The chances
> are high (though not 100%) that one will see this:
I noticed this today when pushing to GitHub (I suppose they have very
recently upgraded?) from Linux, so this is neither specific to 'git
pull' nor to macOS.
I'm sure the culprits are commits cd1096b282 (pager: add a helper
function to clear the last line in the terminal, 2019-06-24) and
5b12e3123b (progress: use term_clear_line(), 2019-06-24) with the
added complication of communicating with a remote.
If the standard error of 'git pull/push' is connected to a terminal,
then it will tell the transport helpers and in turn to the 'git
upload-pack/receive-pack' processes on the remote to produce progress
output. However, since those processes run on the other side of the
internet, they don't have any idea about the local terminal (smart or
dumb? how wide?) their progress will end up on, and, consequently,
they assume the worst, i.e. standard-width dumb terminal, and use 80
spaces to cover up the previously displayed progress line.
I'm not sure how to handle the situation. A few ideas to consider:
1. Update 'git upload-pack/receive-pack' to use some kind of magic
character or char sequence instead of a "real" line clearing
sequence, and update 'git pull/push' to replace that magic with
the line clearing sequence appropriate for the terminal.
2. Variant of the above: leave 'git upload-pack/receive-pack' as they
are now, and declare that those 80 spaces indicate when to clear
progress lines. Update 'git push/pull' to catch those 80 spaces,
and replace them with the line clearing sequence appropriate for
the terminal.
3. Update 'git pull/push' to explicitly tell the remote what line
clearing sequence to use.
4. Revert, and go back to calculating how many spaces we need to
append to clear the previously displayed progress line, and hope
that we don't mess it up (or even if we do, it still won't be as
noticable as this).
I suppose this issue affects other git clients as well, so (1), (2),
and (3) might not even be an option.
