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

From: Jeff King <peff@peff.net>
Date: Jul 6, 2010, 14:29 UTC
Message-ID: <20100706142921.GB6666@sigill.intra.peff.net>
In-Reply-To: <AANLkTinZ4UV9in60Y4myfUWv08Vx3OMvh-_YQl2BXSjC@mail.gmail.com>

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

Show 16 quoted lines

> > 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