On Thu, Sep 8, 2011 at 3:27 AM, Jeff King <peff@xxxxxxxx> 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@xxxxxxxxx> 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. -- 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