Re: More gitweb queries..

On Fri, 27 May 2005, Thomas Glanzmann wrote:

quoted

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.