Re: Bugreport: Git responds with stderr instead of stdout

From: Jeff King <peff@peff.net>
Date: Apr 25, 2010, 19:22 UTC
Message-ID: <20100425192207.GA14736@coredump.intra.peff.net>
In-Reply-To: <y2g51dd1af81004251124zc4da759dka2ceebe1d9735fd7@mail.gmail.com>

On Sun, Apr 25, 2010 at 06:24:43PM +0000, Ævar Arnfjörð Bjarmason wrote:

Show 7 quoted lines

> On Sun, Apr 25, 2010 at 18:10, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> > I can't really say if it's actually a bug, or not, but as to your
> > question about where to file a bug report: You just did.  This mailing
> > list is the correct place.
> 
> I've had some issues scripting `git fetch` because on error it'll
> print to stdout and not stderr.

Errors should go to stderr, so I imagine patches would be welcome. Which messages went to stdout?

> Are there some general guidelines for git's utilities that they follow
> in this regard or does each tool just do its own thing?

In practice, each tool does its own thing because they evolved differently and from different authors. I think we are slowly converging on similar behavior, though, as people fix warts. As to exactly what that behavior is, I don't know that anybody has ever enumerated it exactly. Verbose status and progress reports, especially human readable ones, should probably always go to stderr.

The "Switched to a new branch" message that started this thread is correct to go to stderr. If you want to silence the message but keep stderr open for actual errors, the right way is to use "-q".

I tend to think the only thing that should go to stdout is the "main" output of a command. For something like "ls-files", that is obviously the list of files. For something like "checkout", which is about changing the repository and not about querying it, I think there is probably nothing that makes sense on stdout.

-Peff