On Wed, 19 Mar 2008, Junio C Hamano wrote:
>
> Having said that, I am not sure how the auto gc is triggering for your
> (presumably reasonably well maintained) repository that has only small
> number of loose objects. I haven't seen auto-gc annoyance myself (and
> git.git is not the only project I have my git experience with), and Linus
> also said he hasn't seen breakages.
I think it was 'autopacklimit'.
I think the correct solution is along the following lines:
- disable "git gc --auto" entirely when "gc.auto <= 0" (ie we don't even
care about 'autopacklimit' unless automatic packing is on at all)
Rationale: I do think that if you set gc.auto to zero, you should
expect git gc --auto to be disabled.
- make the default for autopacklimit rather higher (pick number at
random: 50 instead of 20).
Rationale: the reason for "git gc --auto" wasn't to keep things
perfectly packed, but to avoid the _really_ bad cases. The old default
of 20 may be fine if you want to always keep the repo very tight, but
that wasn't why "git gc --auto" was done, was it?
Suggested patch appended. Comments?
Linus
---
builtin-gc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 95917d7..16a912a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -25,7 +25,7 @@ static const char * const builtin_gc_usage[] = {
static int pack_refs = 1;
static int aggressive_window = -1;
static int gc_auto_threshold = 6700;
-static int gc_auto_pack_limit = 20;
+static int gc_auto_pack_limit = 50;
static char *prune_expire = "2.weeks.ago";
#define MAX_ADD 10
@@ -163,7 +163,7 @@ static int need_to_gc(void)
* Setting gc.auto and gc.autopacklimit to 0 or negative can
* disable the automatic gc.
*/
- if (gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0)
+ if (gc_auto_threshold <= 0)
return 0;
/*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
