From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 15 Mar 2020 19:39:20 GMT
Subject: Re: [RFC] Universal progress option (was Re: [PATCH] clone: use --quiet when stderr is not a terminal)
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.