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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Apr 8, 2011, 07:41 UTC
Message-ID: <4D9EBC41.4080501@drmicha.warpmail.net>
In-Reply-To: <4D9EB57D.1060402@drmicha.warpmail.net>

Michael J Gruber venit, vidit, dixit 08.04.2011 09:13:

Show 11 quoted lines

> 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