Re: [RFH] revision limiting sometimes ignored

On Tue, 5 Feb 2008, Johannes Schindelin wrote:

quoted

 - 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