Thread (1 message) 1 message, 1 author, 2020-03-13

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

From: Junio C Hamano <hidden>
Date: 2020-03-13 19:42:46

Elijah Newren [off-list ref] 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 ;-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help