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
