Re: v2.22.1 and later regression wrt display of progress indicators

[Taylor Blau <me@ttaylorr.com>]

On Thu, Aug 22, 2019 at 12:29:08PM -0400, Jeff King wrote:
> On Thu, Aug 22, 2019 at 06:07:02PM +0200, SZEDER Gábor wrote:
>
> > 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.
>
> Yes, we moved to v2.22.1 last night. I'll revert those commits on our
> servers until we come up with a more permanent solution upstream.
>
> > 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.
>
> Yes on that final bit. We could always fall back to (4) if the terminal
> information is not available, but given that the benefit is mostly in
> simplifying the code, I don't know if it's worth carrying around _two_
> solutions.

My thoughts exactly. I think that I prefer the solutions in the order
{2, 1, 3, 4}, but (4) seems to be the most feasible by far.

Should we revert the series?

> One interesting bit: we have traditionally used \033[K on the _client_
> side of the sideband demuxer. So I think in the "remote:" case we were
> already handling this correctly, even before your patch.
>
> -Peff
Thanks,
Taylor