[0/2] Revert "progress: use term_clear_line()"

Message

SZEDER Gábor Sept. 16, 2019, 8:54 p.m. UTC

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.

> > I'm not sure how to handle the situation.  A few ideas to consider:

> >   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.

Ok, so here is a patch to revert 5b12e3123b (progress: use
term_clear_line(), 2019-06-24) with proper explanation.

As a bonus there is a new test script exercising the progress display
as well, in particular how it covers up the previous progress line, so
we may have a bit more confidence in it.


SZEDER Gábor (2):
  Revert "progress: use term_clear_line()"
  Test the progress display

 Makefile                    |   1 +
 progress.c                  |  61 ++++++--
 t/helper/test-progress.c    |  81 ++++++++++
 t/helper/test-tool.c        |   1 +
 t/helper/test-tool.h        |   1 +
 t/t0500-progress-display.sh | 286 ++++++++++++++++++++++++++++++++++++
 t/t5541-http-push-smart.sh  |   6 +-
 7 files changed, 421 insertions(+), 16 deletions(-)
 create mode 100644 t/helper/test-progress.c
 create mode 100755 t/t0500-progress-display.sh

Comments

Jeff King Oct. 2, 2019, 3:47 p.m. UTC | #1

On Mon, Sep 16, 2019 at 10:54:10PM +0200, SZEDER Gábor wrote:

> > 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.
> 
> Ok, so here is a patch to revert 5b12e3123b (progress: use
> term_clear_line(), 2019-06-24) with proper explanation.
> 
> As a bonus there is a new test script exercising the progress display
> as well, in particular how it covers up the previous progress line, so
> we may have a bit more confidence in it.

Thanks for doing this. It's especially nice to get test coverage for the
progress meters, which have traditionally been neglected.

I'm a little late on my review, as it looks like this has already hit
next, but it looks pretty good to me.

My only complaint is that I think putting the new "private" bits of the
progress API into the header (with a comment) is a lesser evil than
re-declaring them in test-progress.c (if only because the compiler could
tell us if the two get out of sync). But I can live with it either way.

-Peff