Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > However, your remark about optimizing for the two-head case got me > thinking: should we not rather use the simple algorithm Miklos proposed > for octopus_merge_bases(), even if it is suboptimal? Actually a quick glance at git-merge, a rather large case...esac after that "show-branch --merge-base" tells me that we do not really use the output from that operation and instead we check if we are fast-forward from all the other heads by iterating over them. merge-octupos would accept it as the base but never looks at it. So I think with a proper refactoring of the codepath you probably would not even have to do the blanket "merge-base across all heads" at all. -- 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