Hi, On Tue, 4 Jul 2006, A Large Angry SCM wrote: > Johannes Schindelin wrote: > > 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). > > It works[*] and it does what using the timestamp was trying to do. Namely, > work from "more recent" (or "closer") commits toward "older" (or "farther") > commits until you've gone past the point you care about. > > It's a little late to be changing the structure of a commit and you'd have to > deal with some size/scale issues, but it's do-able. A better idea may be to > generate and keep the generation number on a per repository basis, and you'd > be able to work around changing grafts. Like, inside the cache? I dunno. IMHO it is way too late to change the structure of a commit in that particular manner, _plus_ you would get overflow issues. > [*] Grafts do _really_ nasty things to this. Just like clock skew does now. Grafts can do much nastier things to you, for example having a circular history. _But_ they cannot do that nasty thing outside of your repo. Clock skews can. 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