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

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

Elijah Newren <newren@gmail.com> writes:

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