Re: git push output goes into stderr

[Sitaram Chamarty <sitaramc@gmail.com>]

On Thu, Sep 8, 2011 at 3:27 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Sep 06, 2011 at 09:49:16AM +0200, Clemens Buchacher wrote:
>
>> On Sun, Sep 04, 2011 at 05:57:53PM -0700, Junio C Hamano wrote:
>> > Lynn Lin <lynn.xin.lin@gmail.com> writes:
>> >
>> > > When I create a local branch and then push it to remote. I find that
>> > > the output without error goes into stderr, is this expected?
>> >
>> > Progress output are sent to the stderr stream.
>>
>> But it's not only progress output that goes to stderr in case of
>> git push. Even the summary written in tranport_print_push_status
>> goes to stderr, unless we specify git push --porcelain. Can't we
>> let that part of the output go to stdout unconditionally?
>
> We could, though it makes more sense on stderr to me.
>
> Stdout has always been about "the main program output" and stderr about
> diagnostic messages. With a program whose main function is to generate
> output (e.g., "git tag -l", it's very easy to know that the list of tags
> is the main program output (which you don't want to pollute with
> anything else), and any problems or even general chattiness goes to
> stderr.
>
> But with a program whose main function is to perform an action, like
> "git push", I think there are really two ways to look at it:
>
>  1. There is no main output; any progress or status update is just
>     diagnostic chat, and should go to stderr.
>
>  2. The main output is the status report; it goes to stdout, and
>     progress updates go to stderr.

I always thought if you write stuff to stdout the remote client gets
confused because it is executing to a defined protocol and suddenly
sees unexpected input in the middle.

Bit if *you* are saying this (output random stuff to STDOUT) can
happen if we want it to, clearly I was wrong...

> I think both are equally valid mental models, and both are consistent
> with the philosophy above. If we switch, I wouldn't be surprised to see
> somebody say "why is this going to stdout, it should be on stderr". In
> fact, I seem to recall that we've had this discussion before on the
> list.