Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
- From
Larry D'Anna <larry@elder-gods.org>
- Date
- Feb 10, 2010, 05:55 UTC
- 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)
Show 10 quoted 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