Re: [PATCH] fetch: don't output non-errors on stderr

From: Jeff King <peff@peff.net>
Date: Jun 26, 2010, 06:13 UTC
Message-ID: <20100626061305.GB10290@coredump.intra.peff.net>
In-Reply-To: <7v1vbukcu8.fsf@alter.siamese.dyndns.org>

On Fri, Jun 25, 2010 at 02:43:27PM -0700, Junio C Hamano wrote:

Show 18 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > On Fri, Jun 25, 2010 at 17:25, Junio C Hamano <gitster@pobox.com> wrote:
> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >>
> >>> Before the change error messages were drowned out by git-fetch's
> >>> non-error update notices, which didn't need my attention.
> >>
> >> I don't understand this part; care to elaborate?
> >
> > I have a cron job (github-backup) that calls git fetch. Without this
> > patch I have to run it as '> /dev/null 2>&1' and just rely on the exit
> > code,
> 
> Signaling failure with exit code is _the_ standard practice, no?
> 
> Some people seem to think unclean standard error means some error (most
> notably tcl ;-), but I think they are mistaken.

Agreed. I thought it was intentional for any human-readable progress messages go to stderr. It is true in the case of git-fetch that stdout is not being used for anything, but:

  1. Git should be consistent about where output goes. And other
     programs may actually produce useful output on stdout, which should
     not be mixed with human-readable verbose messages. For the sake of
     those programs, we should be consistent about sending the output to
     stderr.

  2. Fetch may be combined with other operations in script. Consider
     this toy script to print the latest origin/master to stdout:

       #!/bin/sh
       git fetch && git rev-parse origin/master

     The user sees verbose cruft on stderr, but the interesting part is
     on stdout. With your patch, the script is now broken. Yes, it's
     obviously a toy, but I don't think it inconceivable that somebody
     would not want fetch unexpectedly polluting their stdout. Even if
     it would have been a better behavior in the first place (which I
     don't agree with), changing it now means breaking scripts.

The real problem is that git is very chatty compared to other unix programs. Most produce no output at all unless there is an error, or human-readable non-error output on stderr only if it is a tty. We do this already with progress meters, and this output is just another form of progress update. So I think a patch to quell the status table when stderr is not a tty would be better (that still can break some scripts, too, but I am less sympathetic to people trying to save and parse human-readable stderr messages).

Or even easier: is there a reason that "git fetch -q" would not do what you (Ævar) want?

-Peff