Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 2012/4/17 Junio C Hamano <gitster@xxxxxxxxx>: >> >> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html