From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Charles Diza <chdiza@gmail.com>
Cc: Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: v2.22.1 and later regression wrt display of progress indicators
Date: Thu, 22 Aug 2019 18:07:02 +0200 [thread overview]
Message-ID: <20190822160702.GD20404@szeder.dev> (raw)
In-Reply-To: <20190822141928.GA3163@323642-phi-gmno-clahs>
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.
If the standard error of 'git pull/push' is connected to a terminal,
then it will tell the transport helpers and in turn to the 'git
upload-pack/receive-pack' processes on the remote to produce progress
output. However, since those processes run on the other side of the
internet, they don't have any idea about the local terminal (smart or
dumb? how wide?) their progress will end up on, and, consequently,
they assume the worst, i.e. standard-width dumb terminal, and use 80
spaces to cover up the previously displayed progress line.
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.
next prev parent reply other threads:[~2019-08-22 16:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 14:20 v2.22.1 and later regression wrt display of progress indicators Charles Diza
2019-08-22 16:07 ` SZEDER Gábor [this message]
2019-08-22 16:29 ` Jeff King
2019-08-22 16:40 ` SZEDER Gábor
2019-08-22 17:04 ` Jeff King
2019-08-22 17:19 ` Taylor Blau
2019-09-16 20:54 ` [PATCH 0/2] Revert "progress: use term_clear_line()" SZEDER Gábor
2019-09-16 20:54 ` [PATCH 1/2] " SZEDER Gábor
2019-09-16 20:54 ` [PATCH 2/2] Test the progress display SZEDER Gábor
2019-10-02 15:47 ` [PATCH 0/2] Revert "progress: use term_clear_line()" Jeff King
2019-08-22 17:16 ` v2.22.1 and later regression wrt display of progress indicators Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190822160702.GD20404@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=chdiza@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).