Re: More gitweb queries..

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: More gitweb queries..

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:41:58

quoted
quoted
quoted
quoted
"TG" == Thomas Glanzmann [off-list ref] writes:
TG> talking about octopus-merges ... I don't understand how they work. What
TG> happens if one file is touched in every of the 8 trees. How can that be
TG> handled?

You merge by hand and resolve if they have conflicts, just like
what you already do in two head merge case.

Octopus is only about how you record the results.  Instead of
making 7 consecutive "merge from A" "merge from B" to record two
head merges, you just say "I merged these 8 heads" in a single
commit.

Re: More gitweb queries..

From: Thomas Glanzmann <hidden>
Date: 2016-06-15 22:41:58

Hello,
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?
Octopus is only about how you record the results.  Instead of
making 7 consecutive "merge from A" "merge from B" to record two
head merges, you just say "I merged these 8 heads" in a single
commit.
I got that part. :-)

	Thomas

Re: More gitweb queries..

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:41:58


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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help