Re: [PATCH] guilt: Make sure the commit time is increasing

On Tue, Jul 06, 2010 at 03:53:56PM +0200, Erik Faye-Lund wrote:

quoted

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