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

Theodore Tso wrote:

You're right that it's been a while since git has run into problems with 
mild forms of clock skew (even Debian Stable is shipping v1.5.6) but
I think it's better to times in the future if we can at all help it, and it's not
like we're talking about a lot of extra complexity to guilt to test for this.

Sorry, I’m a little lost.  There are five phenomena one could
forbid:

 1. Commits with timestamp equal to or before a parent
 2. Commits with timestamp before a parent
 3. Commits with timestamp unreasonably long before a parent
 4. Commits with timestamp unreasonably long before an ancestor
 5. Commits with timestamp in the future

Git has always been able to cope with #5 (timestamps in the future).
I see no reason to avoid it, except that it is hard to assign a
timestamp for commits on top of that one.

Git’s problem today is #4 (long-term slop).  Maybe as Jeff suggested
"unreasonably long" should defined per repository.  Or we could
measure the kernel’s maximum (something like 120 days?) and make that
a hard limit.

Do #3 a few times, and you get #4.  So ‘commit’ should warn
about it (where ‘unreasonably long’ could be as short as 0 or
1 days).

#2 (nonmonotonic commits) was broken in ancient git; I think it’s too
rigid of a rule to worry about it on that account.  But a variant of
the rationale for avoiding #3 applies to it.

I have never heard of any version of Git copying poorly with #1
(commits with the same timestamp).  Avoiding it artificially leads
inevitably to timestamps in the future when you somehow try to assign
100 timestamps for the series you have rebased on top of a patch
committed a few seconds ago.

Incrementing the timestamp to ensure strictly monotonic commits seems
like a recipe for trouble to me.

For guilt, I think the best thing to do would to save a Date: line
for the author date with the From: and Subject: and then touch
patches with the _current_ date when appropriate to avoid skew.

HTH,
Jonathan