Re: About global --progress option

From: Jeff King <peff@peff.net>
Date: Nov 5, 2015, 07:08 UTC
Message-ID: <20151105070841.GC4725@sigill.intra.peff.net>
In-Reply-To: <CAOc6etbuK7=-8kH60taO8uH+6XNGTFRNGmmkswgP-19bCRNB3Q@mail.gmail.com>

On Thu, Nov 05, 2015 at 12:47:22AM -0600, Edmundo Carmona Antoranz wrote:

Show 10 quoted lines

> On the technical side, I think the global --progress option (and
> removing the option from the builtins) would not add complexity but
> the opposite because setting the flag would be done at the "main git"
> level and then all the builtins would just forget about it and would
> use progress regardless (cause deciding _if_ progress should be shown
> or not won't be up to them anymore) so the code from the builtins to
> support the option would be gone. It would certainly be more complex
> while keeping global and builtin options alive. Anyway, I do
> understand your concerns and will stand down on the topic (as in....
> global --progress who???).

I think you are missing one important element, which is that git programs do not all share a memory space with the main git binary. So you cannot simply set the "progress" variable in the main program and expect everybody to see it. Running "git foo" may invoke a separate "git-foo" program, written in another language entirely.

For that reason, options to the main git binary typically set an environment variable which is communicated to all sub-processes. For an example, see how "--literal-pathspecs" is implemented. So it actually does add some complexity.

That being said, the environment variable can be a good thing. For example, imagine I have a script "git-foo" which runs several commands, including "git-fetch". It's cumbersome for "git-foo" to take a "--progress" option and then pass that down to "git-fetch". If you could instead run:

  git --no-progress foo

and have that flag magically propagate to any git sub-programs which care about showing progress, then that could perhaps make the feature worthwhile (I say perhaps because while it seems plausible to me, I have not heard of anyone actually wanting this feature in practice).

But adding in "git --progress" is an orthogonal decision to removing support for "git <cmd> --progress". I do not see any big advantage to the latter at this point, and a lot of potential negatives as we break scripts and user expectations.

-Peff