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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 13, 2020, 19:42 UTC
Message-ID: <xmqqlfo4avo2.fsf@gitster.c.googlers.com>
In-Reply-To: <CABPp-BHGsED9noSgAt_OH5G8iXOAvS2cjEV-MDL=hjk365=NdQ@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 6 quoted lines

> However, a larger value might be useful in the face of leap seconds
> and ntp time updates, so I should probably move that direction.
>
> Any preferences on whether I should I pick something like 3600 (large
> but easily recognizable), something more round like 10000, or
> something else?

As long as filesystem timestamp monotonically increases, any value that is the same or larger than the time granularity should be OK, and it sounds reasonable for filesystem timestamp to have at least 1 second resolution.

Ehh, do we still need to worry about the ones that has 2 second resolution or coarser? What does "adjust the file timestamp by decrementing 1 second from the current value" do? Do we risk ending up with the same timestamp as we started with?

I have no strong preference between 3600 and 10000, but to me 1 smells a bit iffy. "test-tool chmtime --get -9 file" is still spelled in the same number of bytes as one second offset and has a larger margin ;-)