Hi, On Tue, 4 Jul 2006, Junio C Hamano wrote: > 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. Are you really, really sure this is a remedy? I, for one, am quite sure of the opposite. What you propose is just another time scale, only this time, it is not universally true (not even minus local incompetence to keep the clock accurate). If that should be not true, you always could rely on topo order. Which does not seem to solve the problem for you. Ciao, Dscho - : 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