On Tue, Mar 22, 2016 at 9:14 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Sebastian Schuberth <sschuberth@xxxxxxxxx> 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.
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html