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