Re: A nice, beauty progress metter for Git Clone + a feature request

From: Jeff King <peff@peff.net>
Date: Mar 28, 2023, 17:51 UTC
Message-ID: <20230328175139.GA18558@coredump.intra.peff.net>
In-Reply-To: <CAKc7PVDZ4Ra7s-pyFms1-sGqjYD9b407G1u0A0hHTkQRa-MPkQ@mail.gmail.com>

On Mon, Mar 27, 2023 at 10:59:56AM +0000, Sebastian Gniazdowski wrote:

Show 15 quoted lines

> On Wed, 15 Mar 2023 at 18:02, Jeff King <peff@peff.net> wrote:
> > Now, none of that is _strictly_ necessary. We could just dump the same
> > human-readable progress to the progress command that we dump to stderr
> > now, and it could scrape it for things that look like progress, and pass
> > everything else through. But then, you can already do that with:
> >
> >   git clone --progress ... 2>&1 | my-progress-scraper
> >
> > (and it looks like the asciinema you showed is probably just a
> > syntactically nicer version of that with support from the shell?).
> 
> Yes, that's what the asciinema does  – it pipes git clone --progress
> to a script, and that's pretty much it. That's why I thought about a
> core.pipe option, that would hold the my-progress-scrapper command.
> That's a very easy change, could it be added to git source code?

For the reasons I gave earlier, it has to scrape all of stderr, and not just progress output. I'm still skeptical that this buys a lot over just redirecting stderr entirely via the shell, but it's at least conceptually simple (it's basically the same as a pager for stderr).

The implementation might have some tricky bits to think about, though, since we have an extra process to handle. For real pagers, we take some care to terminate them on close. Maybe we wouldn't need the same here, though (since the filter isn't interactive, and we don't want Git to wait on exiting until it's done).

So I dunno. It might only be a few lines. It just feels like a weird feature to add.

-Peff