Re: git push output goes into stderr

Lynn Lin [off-list ref] 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.

In general, any program or script is buggy if it assumes that some output
that are emitted to the standard error output from programs it invokes
indicates an error (IIRC, that includes tcl/tk).

On Sun, Sep 04, 2011 at 05:57:53PM -0700, Junio C Hamano wrote:

Lynn Lin [off-list ref] writes:

quoted

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?

Clemens

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:

quoted

Lynn Lin [off-list ref] writes:

quoted

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

-Peff

On Thu, Sep 8, 2011 at 3:27 AM, Jeff King [off-list ref] wrote:

On Tue, Sep 06, 2011 at 09:49:16AM +0200, Clemens Buchacher wrote:

quoted

On Sun, Sep 04, 2011 at 05:57:53PM -0700, Junio C Hamano wrote:

quoted

Lynn Lin [off-list ref] writes:

quoted

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.

On Thu, Sep 08, 2011 at 11:12:48AM +0530, Sitaram Chamarty wrote:

quoted

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

For the remote side, yes, we have to be sure not to pollute stdout,
because that's where the protocol is going.. But the status table is
generated on the client side, so stdout is just connected to the user's
terminal there.

We already generate --porcelain status output from push on stdout (and
again, that makes sense to me philosophically, because the user is
asking push to generate the output). So it's clearly not a big deal.
It's just a matter of taste.

-Peff

On Thu, Sep 8, 2011 at 12:37 PM, Jeff King [off-list ref] wrote:

On Thu, Sep 08, 2011 at 11:12:48AM +0530, Sitaram Chamarty wrote:

quoted

quoted

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

For the remote side, yes, we have to be sure not to pollute stdout,
because that's where the protocol is going.. But the status table is
generated on the client side, so stdout is just connected to the user's
terminal there.

 aah ok, that makes sense; thanks.