Re: Okay to invoke merge-recursive with an empty workdir?

From: Jeff King <peff@peff.net>
Date: Sep 13, 2011, 03:59 UTC
Message-ID: <20110913035927.GB4828@sigill.intra.peff.net>
In-Reply-To: <7v4o0h14gv.fsf@alter.siamese.dyndns.org>

On Mon, Sep 12, 2011 at 08:55:12PM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I'm not sure if we were ever using merge-recursive like that. Especially
> > with Elijah's latest patches to handle worktree dirtiness better, I
> > wouldn't be surprised if it has issues.
> 
> I am parsing the above as "seeing the need for such an extensive fix-up,
> it is not surprising if the base code is broken", and I have to agree.

Well, both. I assume that merge-recursive now cares more than ever about what is in the working tree, because I seem to recall Elijah handling some cases with untracked files. And also, his patches have given me no faith whatsoever in the quality of the underlying code. :)

Show 7 quoted lines

> In principle, "git merge" should be usable in an empty working tree in the
> sense that with correctly populated index the absense of the working tree
> file is _meant_ to be treated the same as having the file unchanged from
> the index and the HEAD version, but I suspect that "merge-recursive" is
> pretty much broken with that regard.
> 
> I have much more faith in "git merge -s resolve" performing correctly.

Agreed, though I haven't tried it.

-Peff