James Melvin <jmelvin@xxxxxxxxxxxxxx> writes: > The new --preserve-and-prune option renames old pack files > instead of deleting them after repacking and prunes previously > preserved pack files. > > This option is designed to prevent stale file handle exceptions > during git operations which can happen on users of NFS repos when > repacking is done on them. The strategy is to preserve old pack files > around until the next repack with the hopes that they will become > unreferenced by then and not cause any exceptions to running processes > when they are finally deleted (pruned). This certainly is simpler than the previous one, but if you run git repack --preserve-and-prune sleep for N minutes git repack --preserve-and-prune the second "repack" will drop the obsoleted packs that were preserved by the first one no matter how short the value of N is, no? I suspect that users would be more comfortable with something based on expiration timestamp that gives them a guaranteed grace period, e.g. "--preserve-expire=8.hours", like how we expire reflog entries and loose objects. Perhaps builtin/prune.c can be a source of inspiration?