Re: [RFC_PATCHv4 4/7] submodule init: redirect stdout to stderr

[Stefan Beller <sbeller@google.com>]

On Tue, Mar 22, 2016 at 9:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Sebastian Schuberth <sschuberth@gmail.com> writes:

My commit message is bad, and I should feel bad. ;)
Quoting from 68b939b2f097b6675 (2013-09-18, clone: send diagnostic
messages to stderr, by Jeff who writes the best commit messages):
    Putting messages like "Cloning into.." and "done" on stdout
    is un-Unix and uselessly clutters the stdout channel. Send
    them to stderr.
    ...
    This should not regress any scripts that try to parse the
    current output, as the output is already internationalized
    and therefore unstable.

Quoting another fbf71645d12d302 (Tue Dec 15 16:04:06 2015,
submodule.c: write "Fetching submodule <foo>" to stderr, by Jonathan)
    The "Pushing submodule <foo>" progress output correctly goes to
    stderr, but "Fetching submodule <foo>" is going to stdout by
    mistake.  Fix it to write to stderr.

>> Just wondering, what's Git's policy on this? This message is neither
>> an error nor a warning, but just purely informational. As such it
>> semantically does not belong to stderr, or?

I think the stance of Git is to write only machine readable stuff to stdout,
and essentially all _(translated) stuff (i.e. human readable) goes to stderr as
some sort of help or progress indication.

>

>
> Some people believe that a clean execution should not give anything
> to stderr (Tcl is one example, IIRC), but I think the core part of
> Git takes the opposite stance (probably unix tradition?).  Anything
> that is not the primary output of the program should go to stdout.
>
> We may not have been very strict in code reviews to enfore it, and
> especially on the fringes of the system it may be easy to find
> violators, though.
>