Re: [PATCH] t6022, t6046: fix flaky files-are-updated checks

[Junio C Hamano <gitster@pobox.com>]

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> 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).

> 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.