Re: [RFC] Universal progress option (was Re: [PATCH] clone: use --quiet when stderr is not a terminal)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2020, 19:39 UTC
Message-ID: <xmqqk13l9zmf.fsf@gitster.c.googlers.com>
In-Reply-To: <310a176a-1b30-a479-638e-33a51fb2c896@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

> 2. Update Git's option-parsing to check for --[no-]progress in
>    every builtin (before the builtins do their own parsing).

    git $frotz -e --no-progress other options

Now, without knowing what exactly $frotz is and how it handles its command line options, you cannot tell if you should unset the global "progress" variable. It could be that "-e" is an option that takes one argument (e.g. "git grep -e") in which case, you should not touch the global, or that "-e" is an explicit request to invoke an editor by countermanding anything in the environment or config (e.g. "git merge -e"), in which case you found "--no-progress" that affects the global.

If the parser that kicks in before the commands do their own parsing needs to know that much to correctly understand "--progress" anyway, wouldn't the same amount of effort would allow us to teach these individual commands to understand "--progress" and pass it correctly down to the underlying helpers?

So, "git clone --no-progress" that lets checkout progress may be a bug worth fixing, but I do not think a global switch is a good way forward.

Thanks.