Re: [RFH] revision limiting sometimes ignored

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 5, 2008, 23:59 UTC
Message-ID: <alpine.LFD.1.00.0802051539570.2967@woody.linux-foundation.org>
In-Reply-To: <alpine.LSU.1.00.0802052228280.8543@racer.site>

On Tue, 5 Feb 2008, Johannes Schindelin wrote:

Show 6 quoted lines

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

Well, notice how I said *warn*. Not abort the commit. Not stop. Just make people very aware of the fact that clocks are skewed.

In the case that actually triggered this whole discussion, the problem seems to sadly have been in the original CVS tree (or whatever it was imported from): the project started in 2006, had lots of regular commits up to October 2007, and then suddenly it had a commit that had a date in 2002!

[ For those interested in looking at this, the broken commit in that 
  Tilman's repo was commit 3a7340af2bd57488f832d7070b0ce96c4baa6b54, which 
  is from October 2002, and which is surrounded by commits from October 
  2007, so somebody was literally off by five years ]

In other words, the repo really was pretty broken, and the git behaviour came from that breakage.

One way to work around this kind of thing is to flag broken dates, and yes, we can probably find most of these kinds of random breakages (in the case of the broken repo, we had the parent of the broken commit already parsed, we could have seen that the date was bogus).

But yeah, I have to also admit that exactly *because* the bug came from some import from somewhere else, the date requirement cannot work - I don't want to change even obviously bogus data from an external import.

I don't see a good way to find the breakage efficiently and generally, though. In the particular case that this hit us, it's visible because the breakage is entirely local (ie you can see the broken commit by just looking directly at its parents), but even if you have just *two* commits that are broken in succession, the breakage is no longer locally obvious at the later one.

Nasty.

			Linus