Hi all,
I have a bit of an annoying behaviour in git gc;
there is a repo I regularly do a fetch in, and
this kicks off a gc/prune every time. I remember
there being a heuristic with being that many files
in .git/objects/17 as the gc trigger.
Which is unfortunate if the gc does not actually
reduce the number of files there because they
aren't old enough => gc comes right back.
What can I do there? (This git is a bit old, 2.2.2)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
On Tue, Nov 3, 2015 at 1:44 PM, Andreas Krey [off-list ref] wrote:
Hi all,
I have a bit of an annoying behaviour in git gc;
there is a repo I regularly do a fetch in, and
this kicks off a gc/prune every time. I remember
there being a heuristic with being that many files
in .git/objects/17 as the gc trigger.
Which is unfortunate if the gc does not actually
reduce the number of files there because they
aren't old enough => gc comes right back.
What can I do there? (This git is a bit old, 2.2.2)
Run "git prune". 2.2.2 hides this suggestion to run git-prune in this
case. The next git version will show it back.
--
Duy
On Tue, 03 Nov 2015 16:01:24 +0000, Duy Nguyen wrote:
....
quoted
I have a bit of an annoying behaviour in git gc;
there is a repo I regularly do a fetch in, and
this kicks off a gc/prune every time. I remember
there being a heuristic with being that many files
in .git/objects/17 as the gc trigger.
(It might be a good idea to use a random slot here.)
...
quoted
What can I do there? (This git is a bit old, 2.2.2)
Run "git prune". 2.2.2 hides this suggestion to run git-prune in this
case. The next git version will show it back.
Actually, there is a 'git prune --expire 2.weeks.ago --no-progress'
running under the 'git gc --auto --quiet', and I don't want to drop
the expiry time lightly.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800