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).