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

[Shawn Pearce <spearce@spearce.org>]

Junio C Hamano <junkio@cox.net> wrote:
> 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).

No it didn't.  After doing the pull:

	$ git rev-parse --verify HEAD
	c2e525d97f81bc178567cdf4dd7056ce6224eb58
	$ git rev-parse --verify 931233bc666b^
	c2e525d97f81bc178567cdf4dd7056ce6224eb58

so no the merge result wasn't put into HEAD.  Nothing was done.
Which is good because to do the merge the working directory has
to change but there's a conflict there due to one file being in a
modified state.  Better we don't change HEAD.

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

I think that elsewhere in git-merge we abort without calling dropsave
when things to south.  Which is why I aborted before.

--