From: Linus Torvalds Date: Fri, 27 May 2005 20:17:10 GMT Subject: Re: More gitweb queries.. Message-ID: In-Reply-To: <20050527195552.GA6541@cip.informatik.uni-erlangen.de> On Fri, 27 May 2005, Thomas Glanzmann wrote: > > 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.