Re: Last mile for 1.0

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 6, 2005, 14:37 UTC
Message-ID: <Pine.LNX.4.58.0506060730510.1876@ppc970.osdl.org>
In-Reply-To: <7vekbgufra.fsf@assigned-by-dhcp.cox.net>

On Mon, 6 Jun 2005, Junio C Hamano wrote:

> 
> Yes, this was done from your explicit request not to touch the
> working directory while it works AFAICR.  At least back then,
> not touching the working tree was the _requirement_.

Yes. Now that read-tree verifies that the working directory is clean (at least for any non-identity files), it's a non-issue.

> So is "the new merge world order" you mentioned in the log
> message now require (and assume) the work tree more-or-less
> matches the first head being merged?

Well, without "-u" you should see the old "order doesn't matter" case, but yes, the theory is that the three trees are <base> <current> <merge> for the three-way case, and <current> <new> for the two-way one.

You can get the old behaviour by using

	git-read-tree -m <cur>
	git-read-tree -m <base> <cur> <merge>

where the first read-tree ends up just makign sure that the index file matches the current head (use "-u" or not as you like).

(Side note: the actual read-tree phase should be totally agnostic about whether the current tree is the first, second or third of the trees, since it will happily say "oh, we saw this exact directory entry in _one_ of the trees, so we know it hasn't gotten lost". So for now, order still is left to the final user, but I don't think you should depend on that).

		Linus