Re: [PATCH] git-merge: Reduce heads before trying to merge them

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

Re: [PATCH] git-merge: Reduce heads before trying to merge them

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:37

Linus Torvalds [off-list ref] writes:
2012/4/17 Junio C Hamano [off-list ref]:
quoted
If your current HEAD is an ancestor of one of the commit on that list, the
above does not omit it from the parent list of the resulting merge commit,
but if you performed the same merge while on one of the commit being
merged, your current HEAD will be excluded with reduce_heads(), which
would mean that you will end up recording a different history even though
a merge is supposed to be symmetrical.

In other words, isn't any solution that calls reduce_heads() only on
remoteheads fundamentally wrong and merely papering over the problem?
I think Michał's patch, together with my original one (but not the
fixups later) is actually the right thing to do.

Michał's patch fixes the "log shown multiple times" problem. It also
turns a certain class of octopus merges into trivial common merges,
which is good.

So I'd suggest:
 - undo the two top commits from lt/octopus-simplify
 - apply Michał's patch on top of the remaining one commit

It's not perfect, and I really think we could simplify things a bit
more here, but I think the two commits together fix the problems in
practice.

Hmm?
I was cooking a fix on-and-off since yesterday evening, and sent it out a
few minutes ago. I think the spirit is almost the same as Michał's updated
patch, but it reduces the heads even earlier to catch cases where Michał's
updated patch may misdiagnose arity of the resulting merge due to its use
of remoteheads->next before the list is reduced (namely, the choice of the
default strategy based on how many we are merging).

Re: [PATCH] git-merge: Reduce heads before trying to merge them

From: Michał Kiedrowicz <hidden>
Date: 2016-06-15 22:53:37

Junio C Hamano [off-list ref] wrote:
 
I was cooking a fix on-and-off since yesterday evening, and sent it out a
few minutes ago. I think the spirit is almost the same as Michał's updated
patch, but it reduces the heads even earlier to catch cases where Michał's
updated patch may misdiagnose arity of the resulting merge due to its use
of remoteheads->next before the list is reduced (namely, the choice of the
default strategy based on how many we are merging).
I like your patches, especially how reducing heads is now done in
collect_parents() instead of doing it twice (before merging and in
finish_automerge()).  And that you got rid of global remoteheads too.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help