aboutsummaryrefslogtreecommitdiff
path: root/block-sha1/sha1.c
diff options
context:
space:
mode:
authorDavid Turner <dturner@twosigma.com>2017-02-10 16:28:22 -0500
committerJunio C Hamano <gitster@pobox.com>2017-02-13 15:19:11 -0800
commita831c06a2b639b0f862297672973bef965c7ffcd (patch)
tree0379b3a91f7dfeecc42a6a4a0fb49344e5936c7c /block-sha1/sha1.c
parent3b9e3c2cede15057af3ff8076c45ad5f33829436 (diff)
downloadgit-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