On Mon, 22 May 2006, Jakub Narebski wrote: > > Linus Torvalds wrote: > > > git repack -a > > # > > # Stupid sleep to make sure that nobody is still > > # using any unpacked objects after the pack got > > # generated > > # > > sleep 10 > > git prune-packed > > Is it really necessary (on Linux at least)? Git boast it's atomicity... I don't think it's necessary in practice. But people _should_ realize that removing objects is very very special. Whether it's done by "git prune-packed" or "git prune", that's a very dangerous operations. "git prune" a lot more so than "git prune-packed", of course (in fact, you should _never_ run "git prune" on a repository that is active - you _will_ corrupt it)- Doing "git prune-packed" _should_ be mostly safe on UNIX, since the objects all exist in packs, and anybody who already opened an object will keep the fd open, and not even notice that the name is gone. However, there is at least one race: object lookup "git repack -a -d" ============= ================== - a process does its object database setup. No new pack-file yet. - mv tmp-packfile active-packfile - git prune-packed - the process looks up the object, and doesn't look in the pack-file because it didn't see the pack-file. So it tries to look up an object, fails, and errors out. It's not a fatal error (just re-try) but it could break something like a cvsimport Now, in PRACTICE, I doubt you'd ever hit this. But the fact is, pruning your repository (whether prune-packed or a full prune) is _the_ special operation. It's something that removes a filesystem representation of an object that is otherwise immutable. Linus - : 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