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@xxxxxxxxxxxxxxxxxxx/ 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
