Junio C Hamano venit, vidit, dixit 08.04.2011 22:20: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >> On systems where the local time and file modification time may be out of >> sync (e.g. test directory on NFS) t3306 and t5305 can fail because prune >> compares times such as "now" (client time) with file modification times >> (server times for remote file systems). I.e., these are spurious test >> failures. >> >> Avoid this by setting the relevant modification times to the local time. >> >> Noticed on a system with as little as 2s time skew. >> >> Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> >> --- >> I don't think we can safeguard prune itself properly. A filesystem may be out >> of time sync sporadically (and produce incorrect time stamps) but then be in >> sync when "git prune" is run so that we can't detect it. >> >> t/t3306-notes-prune.sh | 4 ++++ >> t/t5304-prune.sh | 3 ++- >> 2 files changed, 6 insertions(+), 1 deletions(-) >> >> diff --git a/t/t3306-notes-prune.sh b/t/t3306-notes-prune.sh >> index c428217..3114972 100755 >> --- a/t/t3306-notes-prune.sh >> +++ b/t/t3306-notes-prune.sh >> @@ -20,6 +20,10 @@ test_expect_success 'setup: create a few commits with notes' ' >> git add file3 && >> test_tick && >> git commit -m 3rd && >> + COMMIT=$(git rev-parse HEAD) && >> + COMMIT_FILE=.git/objects/$(echo $COMMIT | sed "s/^../&\//") && > > Hmm, the remainder of the test script seems to know this commit is 5ee1c35 > all over the place. Do the above two lines worth it? I found that use of concrete sha1s a bit strange (I didn't run blame...) but have no objection against keeping the new bit in line with the existing test, i.e. + COMMIT_FILE=.git/object/5e/e1c35e83ea47cd3cc4f8cbee0568915fbbbd29 && instead of the 2 lines above. 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