Junio C Hamano wrote: > I am starting to suspect that introducing "generation" header to > the commit objects might actually be a very good thing. For > one thing, rev-list will automatically get the topology always > right if we did so. > > We obviously need to update 'convert-objects' and tell everybody > that they need to rewrite their history if we take this route. > That kind of flag-day conversion used to be an Ok thing to do, > but it is getting harder and harder these days for obvious > reasons, though. Wouldn't it be possible to have not that more complex code if some of the commit objects (newer) would have "generation" header, and some of them (older) wouldn't have it? Git would use generation header if it is present, and current heuristic timestamp based code if it is not present. It would be better of course if the new commits have correct "generation" header, so insertion of "new" commit after "old" commit would have some extra overhead... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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