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

From: Erik Faye-Lund <kusmabite@googlemail.com>
Date: Jul 6, 2010, 13:53 UTC
Message-ID: <AANLkTinZ4UV9in60Y4myfUWv08Vx3OMvh-_YQl2BXSjC@mail.gmail.com>
In-Reply-To: <20100706080322.GA2856@burratino>

On Tue, Jul 6, 2010 at 10:03 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 15 quoted lines

> tytso@mit.edu wrote:
>> On Mon, Jul 05, 2010 at 02:52:38PM -0400, jeffpc@josefsipek.net wrote:
>
>>> if I commit, and immediately after push 10 patches, wouldn't the HEAD end up
>>> with a commit that's ~10 minutes in the future?
>
> I don’t think git has ever required commit dates to be _strictly_
> monotonic.
>
> 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?

-- 
Erik "kusma" Faye-Lund