"prune" prone to clock skew (Re: t3306 failure with v1.7.5-rc1)

[Michael J Gruber <git@drmicha.warpmail.net>]

Michael J Gruber venit, vidit, dixit 08.04.2011 09:13:
> Johannes Sixt venit, vidit, dixit 08.04.2011 09:06:
>> Am 4/8/2011 11:03, schrieb Michael J Gruber:
>>> I get this stupid test failure in test 3 of t3306. The problem is that a
>>> dangling commit does not get pruned away when it should:
>>>
>>> 3rd
>>> test_must_fail: command succeeded: git cat-file -p
>>> 5ee1c35e83ea47cd3cc4f8cbee0568915fbbbd29
>>> not ok - 4 verify that commits are gone
>>>
>>> It's a system where make complains about funny clock (I dunno why) but

(I know now.)

>>> can we make this more robust? The following helps with "sleep 5" but not
>>> with "sleep 4". test_tick does not help. What's going on?

Adding one more observation from that system:

rm GIT-VERSION-FILE ;date; sh ./GIT-VERSION-GEN; date; ls -l --full-time
GIT-VERSION-FILE

Fri Apr  8 09:27:40 CEST 2011
GIT_VERSION = 1.7.5.rc1
Fri Apr  8 09:27:41 CEST 2011
-rw-r----- 1 mjg mjg 24 2011-04-08 09:27:47.000000000 +0200 GIT-VERSION-FILE

Note that the second "date" happens after the creation of
GIT-VERSION-FILE. I can even do this with a simple

rm a;date; touch a; date; ls -l --full-time a
Fri Apr  8 09:31:04 CEST 2011
Fri Apr  8 09:31:04 CEST 2011
-rw-r----- 1 mjg mjg 0 2011-04-08 09:31:11.000000000 +0200 a

Suffice it to say that this is on NFS, and of course the creation date
comes from the NFS server, the "date" from the client... OK, I got that.
Scary.

EXPLANATION:

I guess "prune" looks at some file time stamps (rather than parsing the
commit time proper) so that it is prone to the same client/server clock
skew problems when the repo is not on the local file system.

PROBLEM (?):

I really hope this does not go both ways - imagine a messed server
turning it's clock a few weeks back by accident, and running "git prune"
on the client, or a messed client turning the clock forward... Do we do
proper checks before removing something?

I mean, there's a difference between missing that something is stale and
missing that it is not...

Michael