Re: [PATCH] Return non-zero status from pull if merge fails.

From: Junio C Hamano <junkio@cox.net>
Date: Nov 8, 2006, 05:36 UTC
Message-ID: <7vu01av6tb.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061108051035.GA28498@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

Show 13 quoted lines

> Yes.  Without it:
>
>   $ git checkout -b 931233bc666b^
>   $ echo broken >builtin-pickaxe.c
>   $ git pull . next && echo good merge
>   Updating c2e525d..522da27
>   builtin-pickaxe.c: needs update
>   fatal: Entry 'builtin-pickaxe.c' not uptodate. Cannot merge.
>   good merge
>
> Say what?  There's no way that fast forward was good!  Granted this
> use case is horrible but that fast forward went very, very badly,
> but the caller now thinks it was good.

I think fast forward went Ok in that "git-ls-tree HEAD" gives the correct merge result from pulling next on top of 931233^ (or whatever). I am undecided if we want to keep what dropsave is supposed to remove in that case, but exiting with non-zero to indicate an error condition is needed.

> Hmm; apparently you are correct.  But that seems like magic shell
> voodoo to me.  I honestly didn't expect exit to behave like that.

Get used to it and learn the real shell programming from a traditionalist ;-).

	something-that-could-fail || exit

is a well established idiom.

But I do not mind the extra explicit non-zero exit status too much as long as you are consistent.