Re: Warnings in gc.log can prevent gc --auto from running

From: Jeff King <peff@peff.net>
Date: Jul 31, 2019, 04:28 UTC
Message-ID: <20190731042807.GA26237@sigill.intra.peff.net>
In-Reply-To: <87v9vl57in.fsf@evledraar.gmail.com>

On Mon, Jul 29, 2019 at 02:50:56PM +0200, Ævar Arnfjörð Bjarmason wrote:

Show 12 quoted lines

> > Instead, it may make sense to turn the --write-bitmap-index option of
> > pack-objects into a tri-state: true/false/auto. Then pack-objects would
> > know that we are in best-effort mode, and would avoid warning in that
> > case. That would also let git-repack express its intentions better to
> > git-pack-objects, so we could replace 7328482253, and keep more of the
> > logic in pack-objects, which is ultimately what has to make the decision
> > about whether it can generate bitmaps.
> 
> Sounds like pentastate to me :) (penta = 5, had to look it up). I.e. in
> most cases of "auto" we pick a true/false at the outset, whereas this is
> true/true-but-dont-care-much/false/false-but-dont-care-much with "auto"
> picking the "-but-dont-care-much" versions of a "soft" true/false.

I don't think we care about false-but-dont-care-much. Pack-objects just needs to know whether the bitmaps are the user's expressed intention, or just something that it should do if it's convenient.

I'll see if I can work up a patch to demonstrate.

> On this general topic a *soft* poke about relying to
> https://public-inbox.org/git/8736lnxlig.fsf@evledraar.gmail.com/ if you
> have time. I think a "loose pack" might be a way forward for the loose
> object proliferation, but maybe I'm wrong.

I just left a reply, though I think most of the discussion there is about the actual pruning-corruption race. I'm totally on board with the idea of an "unreachable pack", but AFAIK nobody has produced any patches yet.

> More generally we're really straining the gc.log pass-along-a-message
> facility.

I definitely agree with that. :)

-Peff