"Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Elijah Newren <newren@xxxxxxxxx> > > Several tests wanted to verify that files were actually modified by a > merge, which it would do by checking that the mtime was updated. In > order to avoid problems with the merge completing so fast that the mtime > at the beginning and end of the operation was the same, these tests > would first set the mtime of a file to something "old". This "old" > value was usually determined as current system clock minus one second, > truncated to the nearest integer. Unfortunately, it appears the system > clock and filesystem clock are different and comparing across the two > runs into race problems resulting in flaky tests. Good observation (and if we were doing networked filesystems, things would be worse). > So, instead of trying to compare across what are effectively two > different clocks, just avoid using the system clock. Any new updates to > files have to give an mtime at least as big as what is already in the > file, so define "old" as one second before the mtime found in the file > before the merge starts. Is there a reason why we prefer as small an offset as possible? I am not objecting to the choice of 1 second, but am curious if anything bad happens if we used a larger offset, say, 2 hours. Thanks.
