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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
