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

quoted

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