From: Junio C Hamano Date: Fri, 13 Mar 2020 19:18:24 GMT Subject: Re: [PATCH] t6022, t6046: fix flaky files-are-updated checks Message-ID: In-Reply-To: "Elijah Newren via GitGitGadget" writes: > From: Elijah Newren > > 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.