Re: "prune" prone to clock skew (Re: t3306 failure with v1.7.5-rc1)

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

Jeff King <peff@peff.net> writes:

> So I don't know that it's worth fixing, nor do I know what your "proper
> checks" would be. We could open up commits we're about to prune and
> check their timestamps for age. That wouldn't help blobs and trees. For
> them, we could make a guess as to their age by seeing if they're
> connected to any dangling commits, and using the commit timestamp. But
> that will only cover some objects, and it is also still vulnerable to
> certain types of clock skew (though it is more robust, since you would
> need a client and server with one type writing the objects, and then
> another skewed client doing the prune, which is even less likely).

I don't personally think this is worth addressing, but as I was Cc'ed,
I'll try.

If we at least know that the object store is contained within a single
filesystem whose clock is at least guaranteed to monotonically increase,
one possible workaround would be to touch a garbage file and read its
timestamp, instead of grabbing the current time from the local clock, no?