Jeff King <peff@xxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html