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, 23:59 UTC
Message-ID: <xmqq5zf59nkb.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqk13l9zmf.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 9 quoted lines

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

You can sort-of work it around by introducing "--[no-]progress" that is taken as an option to the "git" command, just like "--[no-]pager" is, to work around the issue above. But I have a feeling that you did not like the resulting UI, which is totally backward incompatible and break users' existing scripts and habits.

The resulting UI built around "git --[no-]progress subcmd" may feel much nicer, and I suspect that it would be something we would have picked, if we had today's experience back when we started adding progress display to individual subcommands.

As long as a clear transition path can be drawn, I do not necessarily object to such a direction that (1) introduces the global level "git --[no-]progress $subcmd" option, and (2) deprecates and eventually removes the "--progress" option at the subcommand level.