Re: [PATCH] clone: use --quiet when stderr is not a terminal

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 14, 2020, 17:10 UTC
Message-ID: <xmqqh7yqc16w.fsf@gitster.c.googlers.com>
In-Reply-To: <pull.581.git.1584133742475.gitgitgadget@gmail.com>

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 16 quoted lines

> From: Derrick Stolee <dstolee@microsoft.com>
>
> "git clone" is used by many build systems to download Git code before
> running a build. The output of these systems is usually color-coded to
> separate stdout and stderr output, which highlights anything over stderr
> as an error or warning. Most build systems use "--quiet" when cloning to
> avoid adding progress noise to these outputs, but occasionally users
> create their own scripts that call "git clone" and forget the --quiet
> option.
>
> Just such a user voiced a complaint that "git clone" was showing "error
> messages" in bright red. The messages were progress indicators for
> "Updating files".
>
> To save users from this confusion, let's default to --quiet when stderr
> is not a terminal window.

This is the kind of behaviour change that makes me (and probably others who have been with the project long enough) to say "it is certain that some other users and tools are relying on the current behaviour and their expectation, when explained, would look just as sensible, if not more, than 'any output to the standard error stream is an error', which is the justfication given for this change."

I would not be surprised if a GUI program is counting the bytes coming to the progress output to show the equivalent with bits on the screen, for example. They would say "Git has always given progress output to the standard error stream. We, as any other sensible folks, know that they are not errors and won't give a misleading and alarming messages in red. We could change our program to pass --progress but why should we be the one who are forced to do such a change", and I do not have *any* excuse I find sensible enough to give them.

I do not mind queuing this (or any similar backward compatibility breaking changes) and merging it down to 'next', but if we were plan to have it in a tagged release, I'd prefer to keep it in 'next' for at least a few releases before doing so, and under three conditions: major organizations and those who build tools around Git promise me that they adopt 'next' for their developers and users early, and that they actively measure and report potential damages before it is advanced to 'master', and that they won't let their users complain after it hits a tagged release.

If the world and userbase were like today back when "clone" learned the --quiet option and showing the progress meter 15 years ago, I suspect that we may have chosen this way from the beginning, though.