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

From: Shawn Pearce <spearce@spearce.org>
Date: Nov 8, 2006, 05:52 UTC
Message-ID: <20061108055257.GC28498@spearce.org>
In-Reply-To: <7vu01av6tb.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 19 quoted lines

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