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

[Junio C Hamano <junkio@cox.net>]

Shawn Pearce <spearce@spearce.org> writes:

> 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.