On Fri, Apr 08, 2011 at 09:41:53AM +0200, Michael J Gruber wrote: > EXPLANATION: > > I guess "prune" looks at some file time stamps (rather than parsing the > commit time proper) so that it is prone to the same client/server clock > skew problems when the repo is not on the local file system. Of course. Remember that prune is removing all sorts of objects, not just commits. In the case of a tree or blob, we have nothing else to go on besides the filesystem timestamp. > PROBLEM (?): > > I really hope this does not go both ways - imagine a messed server > turning it's clock a few weeks back by accident, and running "git prune" > on the client, or a messed client turning the clock forward... Do we do > proper checks before removing something? I don't think anybody has ever cared. These things are, after all, unreferenced by either current refs or the reflog. I think the purpose of the 2-week grace period is more to prevent prune from deleting objects from an in-progress operation before that operation has had a chance to write its refs. So one problem scenario is that the prune on the machine with the bad clock would delete objects from something like a push in progress. But I think it's just so unlikely to happen that your repo is on a remote server, _and_ the client and server clocks are skewed by more than two weeks, _and_ you're running prune, _and_ somebody is pushing into the repo simultaneously, that nobody has really bothered to try to do better. Note that if you access the same repo over a filesystem share by two clients with different clocks, you can also expire reflog entries prematurely. But that is a 90-day window. 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). -Peff -- 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