Re: [PATCH] gc: remove redundant check for gc_auto_threshold

From: Brandon Casey <drafnel@gmail.com>
Date: Oct 10, 2018, 22:29 UTC
Message-ID: <CA+sFfMeOpj4V+KszboVVQSoaW2yDgpfDNGwK9ZrNfGmOOAhPtQ@mail.gmail.com>
In-Reply-To: <20181010193235.17359-1-avarab@gmail.com>

On Wed, Oct 10, 2018 at 12:32 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 24 quoted lines

>
> Checking gc_auto_threshold in too_many_loose_objects() was added in
> 17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.",
> 2007-09-17) when need_to_gc() itself was also reliant on
> gc_auto_pack_limit before its early return:
>
>     gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0
>
> When that check was simplified to just checking "gc_auto_threshold <=
> 0" in b14d255ba8 ("builtin-gc.c: allow disabling all auto-gc'ing by
> assigning 0 to gc.auto", 2008-03-19) this unreachable code should have
> been removed. We only call too_many_loose_objects() from within
> need_to_gc() itself, which will return if this condition holds, and in
> cmd_gc() which will return before ever getting to "auto_gc &&
> too_many_loose_objects()" if "auto_gc && !need_to_gc()" is true
> earlier in the function.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>
> I had this in my tree as part of some general gc cleanups I was
> working on, but since it's trivially considered as a stand-alone topic
> and unlikely to conflict with anything I or anyone else has planned
> I'm sending it as a one-off.

Hmm, yeah you're right that the check seems to be redundant for the current uses of too_many_loose_objects(). I don't feel strongly about it, but I think an argument could be made that it makes sense for too_many_loose_object() and too_many_packs() to each inspect the configuration variable that controls them and detect when they're disabled, rather than having one of them require that the check be done beforehand. Again, I don't feel strongly about it, but I'm not sure this change actually improves the code.

-Brandon