Linus Torvalds wrote: > [...] 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)- Would it be possible to make 'git prune' command repository corruption safe, even if some information might be lost (like 'git add')? Or do _corruption_ mean some recoverable only information is lost? Not always one can use "one repository per developer" workflow. One of the solution would be to to use reader/writer lock (filesystem semaphore), with each command modyfying repository performing locking, and git-prune waiting on lock until noone is accessing repository. Of course the problem is with OS and filesystems which does not support locking, and with stale locks... Second solution would be to [optionally] wait until no process is accessing repository, copy repository in some safe place, [optionally] calculate checksum, prune, [optionally] check if the repository was modified meanwhile and either abort or repeat, and finally copy pruned repository back. -- Jakub Narebski Warsaw, Poland - : 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