From: Larry D'Anna <larry@elder-gods.org>
Date: Wed, 10 Feb 2010 05:55:29 GMT
Subject: Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
Message-ID: <20100210055529.GA1566@cthulhu>
In-Reply-To: <20100210053937.GF28526@coredump.intra.peff.net>

* Jeff King (peff@peff.net) [100210 00:41]:
> I have not actually been running these patches, just reading them, but
> my impression was the goal _was_ to squelch all of the stderr cruft. But
> if we are not even close, then probably we should just give up and
> callers should "2>/dev/null".

Personally, I don't really care about squelching stderr cruft.  All I really
want is for what goes to stdout be sane and the calling script to be able to
unambiguously figure out what happened, including

* which refs go to which remotes 

* whether or not some mysterious error occurred (beyond those mentioned in the
  ref status lines)

> I had initially endorsed it, but now I am having second thoughts.
> Especially if the "usual" calling convention is to redirect stderr as
> above, then we are probably missing out on any useful error messages
> that accompany a failure return, anyway.  So maybe the sane thing to do
> is to leave the exit code alone, and include a --porcelain output line
> that either says "Everything was OK, see individual ref status" or "We
> couldn't even talk to the other side". Then the status code is
> irrelevant, and stdout contains all of the useful information (and if
> you don't get an error or OK message, you know there was some
> serious error like a broken git installation).

That serves my purposes as well as the exit code would.  Is this the consensus?

     --larry