summaryrefslogtreecommitdiff
path: root/builtin/blame.c
diff options
context:
space:
mode:
authorÆvar Arnfjörð Bjarmason <avarab@gmail.com>2018-02-28 23:04:25 +0000
committerJunio C Hamano <gitster@pobox.com>2018-03-01 11:34:06 -0800
commit095c741edd1d9604b6c285000a836721fd69f051 (patch)
treefe36081063fbd2b9b828859d7e6756da2c586b0e /builtin/blame.c
parent38e79b1fdab9244e1727d0698afcf3bb8956c0a4 (diff)
downloadgit-ab/gc-auto-in-commit.tar.gz
commit: run git gc --auto just before the post-commit hookab/gc-auto-in-commit
Change the behavior of git-commit back to what it was back in d4bb43ee27 ("Invoke "git gc --auto" from commit, merge, am and rebase.", 2007-09-05) when it was git-commit.sh. Shortly afterwards in f5bbc3225c ("Port git commit to C.", 2007-11-08) when it was ported to C, the "git gc --auto" invocation went away. Since that unintended regression, git gc --auto only ran for git-am, git-merge, git-fetch, and git-receive-pack. It was possible to write a script that would "git commit" a lot of data locally, and gc would never run. One such repository that was locally committing generated zone file changes had grown to a size of ~60GB before a daily cronjob was added to "git gc", bringing it down to less than 1GB. This will make such cases work without intervention. I think fixing such pathological cases where the repository will grow forever is a worthwhile trade-off for spending a couple of milliseconds calling "git gc --auto" (in the common cases where it doesn't do anything). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/blame.c')
0 files changed, 0 insertions, 0 deletions