git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: A nice, beauty progress metter for Git Clone + a feature request
Date: Wed, 15 Mar 2023 14:02:18 -0400	[thread overview]
Message-ID: <ZBIIKqAIF+aF8vvx@coredump.intra.peff.net> (raw)
In-Reply-To: <CAKc7PVA14_mjZeuED1Ee0Mu5YoCSrR4FNNhSEKFHmnKnc-gESQ@mail.gmail.com>

On Fri, Mar 10, 2023 at 11:37:49AM +0000, Sebastian Gniazdowski wrote:

> Check out: https://asciinema.org/a/566216
> 
> Feature request is: add a pipe={cmd} option to git, that would just
> pass through the git clone --progress output into {cmd}. This is
> EXTREMELY EASY TO DO SO, ONLY
> 
> FILE *pipe=popen(cmd_option_str, "w") ;
> 
> is needed, and one can then write to `pipe` file handler.

I think it would be neat to have options for prettier progress output.
Unfortunately, it's not quite that easy.

Imagine we had a config option, progress.command or something, which
specified a shell command to which we'd pipe machine-readable progress,
and it would turn it into something pretty. There are two gotchas I can
think of immediately:

  1. Progress is often created by multiple processes. For example, in a
     clone, you might see progress output from index-pack as it receives
     the pack and resolves the delta. But then you might also see
     progress during the checkout phase, as we write out the worktree
     files.

     One solution is to say that each progress command is independent,
     and we'd simply run it twice, once for each context. That's easy to
     do, but restricts some fancier options that a command could do.

     Another is for the parent clone command to kick off a progress
     process, and then tell child processes (perhaps through the
     environment) which descriptor they can use to talk to the progress
     command.

  2. Sometimes progress is shoved through a single descriptor along with
     other human-readable messages. I'm thinking specifically of the
     output you get from a clone/fetch _before_ we start receiving pack
     bytes from the server. There the server is giving progress on
     preparing the fetch. It comes over a sideband channel through Git's
     protocol, along with any regular stderr messages, and the client
     side just dumps it all to the local stderr.

     Obviously the remote side is not going to run our custom progress
     command. But it would be possible to add a protocol extension that
     says "hey, please send machine-readable progress data over sideband
     4" or something.

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?).

-Peff

  reply	other threads:[~2023-03-15 18:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKc7PVD_65vB5+meeO3xcu4ASbqr85LBGUO8Ntb7SvbO+NNHmQ@mail.gmail.com>
2023-03-10 11:37 ` A nice, beauty progress metter for Git Clone + a feature request Sebastian Gniazdowski
2023-03-15 18:02   ` Jeff King [this message]
2023-03-27 10:59     ` Sebastian Gniazdowski
2023-03-28 17:51       ` Jeff King
2023-03-28 20:49         ` Sebastian Gniazdowski

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=ZBIIKqAIF+aF8vvx@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=sgniazdowski@gmail.com \
    /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).