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

From: Jeff King <peff@peff.net>
Date: Aug 22, 2019, 17:04 UTC
Message-ID: <20190822170435.GA26163@sigill.intra.peff.net>
In-Reply-To: <20190822164032.GF20404@szeder.dev>

On Thu, Aug 22, 2019 at 06:40:32PM +0200, SZEDER Gábor wrote:

Show 7 quoted lines

> > 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 think it's sufficient to revert only 5b12e3123b (progress: use
> term_clear_line(), 2019-06-24).  I only mentioned cd1096b282 here
> because it better explains the reasons for having term_clear_line(),
> and an other patch depends on that function as well.

Yes, that's what we did. :) It's out now, so everybody should see the fix.

Show 6 quoted lines

> > 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.
> 
> Gah, I feared that the term "sideband multiplexer" will soon come up
> in this discussion...

It may open up some new options for us, though.

If we know on the server side that we are serving a remote request (which is easy, and does not require client cooperation), can we assume that the other side will show any sideband lines with its own end-of-line clearing?

I'm not sure. Git does and always has (and even on a dumb terminal makes a token effort at throwing some spaces in ;) ). But I'm not sure if other clients do (and they of course might not even be displaying to a terminal at all, if they're pulling sideband data into a GUI dialog or similar).

-Peff