On Sat, 9 Sep 2006, Jon Smirl wrote: > > When a merge happens could git fix things up in the database by adding > a corrected, hidden time stamp that would keep things from having an > out of order time sequence? That way you wouldn't need to rediscover > the out of order commit each time the tree is generated. I don't think any such algorithm exists, and it's too late now ;) I was thinking of some "sequence number" algorithm, but the thing is, it's not _merges_ that are the problem per se, it's the "branch points". And you don't actually know that a commit is a branch point in advance: it's a branch point not because you branched, but because somebody else happened to use the same parent as the basis of their independent work. So we could make the rule be something like "when we commit, the new commit must have a datestamp that is equal to or in the future from the parent commits". However, that results in some really strange problems in a distributed environment, where _if_ somebody has their clock set wrong, you'll end up either unable to merge with them, or you have to generate a totally bogus time yourself (which then moves up the chain). It might be simpler to then not think of the thing as a "date" at all, but as a pure sequence number. Then the rule would be: a new commit has to have a sequence number that is "max(of-the-parent-sequence-numbers) + 1". That _may_ or may not actually help. It was discussed (a bit) early on - summer-05 - but I wasn't convinced enough that it would help that I was willing to change the format and add that sequence number. I still am not. I'm not even sure it would really work. In other words, it's probably just not worth it. It's better to just say "dates don't really _matter_, and all that matters is the parenthood information". Which is really what git does - the dates aren't _important_ for any real operation, they are literally just a heuristic. But hey, maybe somebody can come up with some operation that becomes _much_ cheaper with the above kind of sequence number. It shouldn't be hard to test.. Linus - 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