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

[Junio C Hamano <gitster@pobox.com>]

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

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