Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > Shouldn't the repository be locked against operations like prune while > a commit is in progress anyway? That seems like it's pretty prudent > and reasonable to me -- doing otherwise is just asking for a zillion > little race conditions. The primary problem is not "while a commit is in progress" anyway. I do not think of a single sane reason to run git-prune from a cron job in a repository that is used for an active development. It would make sense for management types to run count-objects from a cron job and yell at offenders to repack, but even then the primary disk saving and performance enhancement would come from repacking and not from pruning. Especially, 1.5.0 and onwards the objects reachable from reflog are protected from pruning and reflogs are enabled by default for developer repositories with working trees, even rewind and rebae would not create crufts (the only two exceptions that create cruft are running "git add" more than once on the same file between commits to leak blobs and intermediate tree objects recursive merge needs to make when there are more than one common ancestors). It is a possibility to have a single timestamp file that any command that intends to eventually update refs should touch before it starts creating any object. Then prune can stat the file and remember its timestamp before it starts reading the refs, and then before starting to actually prune the objects it can stat the file again and if the timestamp is different it can abort. Commit, receive-pack (invoked by git-push from the remote side), fetch-pack (invoked by clone, fetch and pull), etc. all needs to touch the file upfront before they create even a single object. But that would create a very hot spot on the filesystem, and I am not sure what its ramifications are. My take on this issue is rather different. I do agree with you that prune is a rare enough operation, and I think it should not penalize the primary thing developers would want to do many times an hour. I think its much simpler and saner to teach people not to run prune in an uncontrolled way. We may want to remove the call to git-prune from git-gc, and tell people that if they want to run something from a cron job, run git-gc and not git-prune. - 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