On Fri, Jun 25, 2010 at 02:43:27PM -0700, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
> > On Fri, Jun 25, 2010 at 17:25, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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
--
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