Re: [PATCH v2] repack: Add option to preserve and prune old pack files
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 10, 2017, 23:43 UTC
- Message-ID
- <xmqqmvcswvdc.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170310220020.2666-1-jmelvin@codeaurora.org>
James Melvin <jmelvin@codeaurora.org> writes:
Show 10 quoted lines
> 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?