Junio C Hamano <gitster@xxxxxxxxx> writes: > In a workflow where topic branches are first merged to the 'next' > integration branch to be tested before getting merged down to the > 'master' integration branch to be consumed by the end users, merging > the 'master' branch back to the 'next' happens after topics graduate > to 'master' and release notes entries are written for them. > > Git finds many merge bases between 'master' and 'next' while > creating this merge. In addition to the tip of 'master' back when > we made such a merge back from 'master' to 'next' was made the last > time, which is the most reasonable merge base to explain the > histories of both branches, all the tips of topic branches that > graduated recently are merge bases. Because these tips of topic > branches were already in 'next', the tip of 'next' reaches them, and > because they just graduated to 'master', the tip of 'master' reaches > them, too. And these topics are independent most of the time (that > is the point of employing the topic-branch workflow), so they cannot > be reduced. The idea here is to exclude tips of topic branches as "obviously less useful as merge bases than the mainline commit". Aside from the fact that the approach is purely a heuristic that heavily relies on convention aka "topic branch workflow", there is a caveat (or more that I haven't thought of yet). One is that there may be no merge base found that is on the first parent chain with this particular patch. When any of the topics that just graduated to 'master' was forked off of 'master' after the latest merge from 'master' to 'next' was made, then the merge base on the first parent chain, i.e. the commit on 'master' that was merged to 'next' the last time, will be an ancestor of the tip of that recently forked topic, which is another common ancestor between 'master' and 'next' being merged (hence removed as redundant). We will be left with only the merge bases that are off first-parent chain, and I think "git merge" will say "no related histories; I won't merge them". I do not know if that is a problem in practice, but if it turns out to be, it probably can be corrected by updating the way how the paint_down_to_common() function works. It still stops traversal, even with this patch, when a commit is found to be common and place it to the "potential merge bases" list, but instead we could keep digging until we hit a commit that is common between PARENT1 and PARENT2 and also is on the first-parent chain, without declaring that we found one result. But that probably ends up being the same as ignoring all side branches from merges and finding merge bases only paying attention to the first-parent chain.