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

[Junio C Hamano <gitster@pobox.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.