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

[Jeff King <peff@peff.net>]

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

> > 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