On Tue, Jul 06, 2010 at 03:53:56PM +0200, Erik Faye-Lund wrote: > > At one point rev-list did require monotonic --- i.e., the committer > > date of each commit had to be equal to or later than that of each of > > its parents) with no clock skew but that was considered a bug and > > fixed by v1.5.5-rc1~16 (Make revision limiting more robust against > > occasional bad commit dates, 2008-03-17) > > > > This might be a stupid question, but I'm not entirely clear on why > it's not a strict requirement; surely it would be easy to ensure that > the commit-time is at least as big as the parents when generating the > commit...? > > Is it to avoid the case where a user commits with the clock set to > some point (potentially far) in the future, so all subsequent commits > would have the same, artificially high commit time? Or is there some > other reason I can't think of? You can have clock skew between distributed developers. So imagine you commit at 5:00pm, then I pull at 5:01pm, but it turns out your clock is two minutes fast, so it's actually 4:59pm. What should my commit do? If I insist on monotonic increases, then my clock gets pushed forward artificially by your fast, broken clock (which is probably not the end of the world; in practice, if your clock is N seconds fast, there will presumably be some N second period where I'm not making a commit, and the clocks can "catch up" with each other). -Peff -- 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