Re: More gitweb queries..

From: Linus Torvalds <torvalds@osdl.org>
Date: May 27, 2005, 20:17 UTC
Message-ID: <Pine.LNX.4.58.0505271307510.17402@ppc970.osdl.org>
In-Reply-To: <20050527195552.GA6541@cip.informatik.uni-erlangen.de>

On Fri, 27 May 2005, Thomas Glanzmann wrote:

Show 5 quoted lines

> > You merge by hand and resolve if they have conflicts, just like
> > what you already do in two head merge case.
> 
> I see. Does that mean that 'git-ls-files --unmerged' will report upto 9
> stages per file?

No, you must always merge trees one by one against each other. The simplest ordering is to merge trees 1-2 first, then the result of that with 3, then the result of _that_ with 4 etc etc, but you can - if you really want to - do 1-2 and 3-4 separately and then merge those two together.

The ordering does actually end up mattering a bit when it comes to deciding on parenthood, but in the end you will have used the same most remote common parent for _one_ of the merges anyway, so assuming all the merges were automatically resolved by the regular 3-way thing, I claim that it doesn't really matter noticeably (*).

Regardless, you'd end up with seven "git-read-tree -m x y z" invocations (plus possibly a few git-merge-cache calls), and one final commit.

		Linus

(*) I bet you could find some case where the ordering either generates a create-create conflict or it doesn't, depending on how you pair things up.

But I also claim that you'd be crazy to do a octopus merge for something like that anyway, and that the reason to do one is that you've had five totally disjoint things you've been working on - like updating five different drivers or five different filesystems in different branches, and there are no conflicts however you turn.