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

From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
	"Taylor Blau" <me@ttaylorr.com>,
	"Charles Diza" <chdiza@gmail.com>,
	"Johannes Schindelin" <johannes.schindelin@gmx.de>,
	"SZEDER Gábor" <szeder.dev@gmail.com>
Subject: [PATCH 0/2] Revert "progress: use term_clear_line()"
Date: Mon, 16 Sep 2019 22:54:10 +0200	[thread overview]
Message-ID: <20190916205412.8602-1-szeder.dev@gmail.com> (raw)
In-Reply-To: <20190822162907.GA17013@sigill.intra.peff.net>

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

-- 
2.23.0.331.g4e51dcdf11