diff options
author | David Turner <dturner@twosigma.com> | 2017-02-10 16:28:22 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-02-13 15:19:11 -0800 |
commit | a831c06a2b639b0f862297672973bef965c7ffcd (patch) | |
tree | 0379b3a91f7dfeecc42a6a4a0fb49344e5936c7c /block-sha1/sha1.c | |
parent | 3b9e3c2cede15057af3ff8076c45ad5f33829436 (diff) | |
download | git-a831c06a2b639b0f862297672973bef965c7ffcd.tar.gz git-a831c06a2b639b0f862297672973bef965c7ffcd.tar.xz |
gc: ignore old gc.log files
A server can end up in a state where there are lots of unreferenced
loose objects (say, because many users are doing a bunch of rebasing
and pushing their rebased branches). Running "git gc --auto" in
this state would cause a gc.log file to be created, preventing
future auto gcs, causing pack files to pile up. Since many git
operations are O(n) in the number of pack files, this would lead to
poor performance.
Git should never get itself into a state where it refuses to do any
maintenance, just because at some point some piece of the maintenance
didn't make progress.
Teach Git to ignore gc.log files which are older than (by default)
one day old, which can be tweaked via the gc.logExpiry configuration
variable. That way, these pack files will get cleaned up, if
necessary, at least once per day. And operators who find a need for
more-frequent gcs can adjust gc.logExpiry to meet their needs.
There is also some cleanup: a successful manual gc, or a
warning-free auto gc with an old log file, will remove any old
gc.log files.
It might still happen that manual intervention is required
(e.g. because the repo is corrupt), but at the very least it won't
be because Git is too dumb to try again.
Signed-off-by: David Turner <dturner@twosigma.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'block-sha1/sha1.c')
0 files changed, 0 insertions, 0 deletions