Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > We could introduce a time.maximumSkew variable, and just walk only > that much further when traversing the commits. We could have had "commit generation number" in the commit object header, and use that instead of commit timestamps for these traversal purposes. The generation number for a commit is defined to be max(generation number of its parents)+1 and we prime the recursive this definition by defining the generation number for the root commit to be one. A moral equivalent alternative would be to notice that the commit timestamp we are going to use to create for a new commit is smaller than one of the commit timestamps of its parent commits and adjust the commit timestamp in such a case by git-commit-tree, perhaps with a warning. These are pretty much water under the bridge by now, for two reasons. One is that I think it is better to make the tools that use get_merge_bases() prepared for the case the function includes suboptimal bases anyway, and the other is once we do that this is not a strong enough justification to modify the commit object format. - : 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