Re: [RFH] revision limiting sometimes ignored

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 5, 2008, 22:34 UTC
Message-ID: <alpine.LSU.1.00.0802052228280.8543@racer.site>
In-Reply-To: <alpine.LFD.1.00.0802051300050.3110@woody.linux-foundation.org>

Hi,

On Tue, 5 Feb 2008, Linus Torvalds wrote:

Show 5 quoted lines

> I really wonder if the right thing is not simply to admit that we consider 
> the commit time meaningful (within some fudge factor!), and then do:
> 
>  - make commit warn if any parent commit date is in the future from the 
>    current commit date (allow a *small* fudge factor here, say 5 minutes).

5 minutes seems a little narrow to me. I think we can even go with 86400 seconds.

Show 5 quoted lines

>  - teach fsck to complain about parent commits being in the future from 
>    their children (allow the same small fudge factor).
> 
>  - make the revision walking code realize that if times are too close to 
>    each other, it should walk a bit further back...

There is one big problem, though. Sometimes your clock is set wrong for all the wrong reasons. Look at

	http://article.gmane.org/gmane.comp.version-control.git/67848/raw

for example (look at the Original-Date). If that happens without being noticed (and it happened here!), and it is pushed, you have to live with it.

_However_, I could imagine that you can get most of such errors by doing the same as gmane: realise that the clock skew is into the future, and just take the sensible date.

In our case, this would mean that the revision walker should realise that a child whose date is not older than its parent commit must be wrong. And just take the parent's date instead (but maybe only for the purpose of limiting).

Hmm?

Ciao, Dscho