Re: [PATCH] t6022, t6046: fix flaky files-are-updated checks
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 13, 2020, 19:18 UTC
- Message-ID
- <xmqqtv2sawsf.fsf@gitster.c.googlers.com>
- In-Reply-To
- <pull.725.git.git.1584125875550.gitgitgadget@gmail.com>
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 11 quoted lines
> From: Elijah Newren <newren@gmail.com> > > 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).
Show 5 quoted lines
> 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.