Re: [PATCH] fix an error message in git-push so it goes to stderr
From: Larry D'Anna <hidden>
Date: 2016-06-15 22:48:11
* Jeff King (peff@peff.net) [100205 10:06]:
On Thu, Feb 04, 2010 at 07:41:40PM -0500, Larry D'Anna wrote:quoted
Having it go to standard output interferes with git-push --porcelain. --- builtin-push.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)diff --git a/builtin-push.c b/builtin-push.c index 5633f0a..0a27072 100644 --- a/builtin-push.c +++ b/builtin-push.c@@ -124,9 +124,9 @@ static int push_with_options(struct transport *transport, int flags) return 0; if (nonfastforward && advice_push_nonfastforward) { - printf("To prevent you from losing history, non-fast-forward updates were rejected\n" - "Merge the remote changes before pushing again. See the 'Note about\n" - "fast-forwards' section of 'git push --help' for details.\n"); + fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n" + "Merge the remote changes before pushing again. See the 'Note about\n" + "fast-forwards' section of 'git push --help' for details.\n");I agree that stderr is a more sensible place for such a message to go, but shouldn't the porcelain output format just suppress it entirely?
I think you're right. There are some other messages that are similar that
should probably also be suppressed.
Also it seems to me that git push --dry-run --porcelain should exit successfully
even if it knows some refs will be rejected. The calling script can see just
fine for itself that they will be rejected, and it probably still wants to know
whether or not the dry-run succeeded, which has nothing to do with whether or
not the same push would succeed as a not-dry-run.
--larry