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

On Wed, 15 Mar 2023 at 18:02, Jeff King [off-list ref] wrote:

quoted

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