On Sun, Jun 23, 2019 at 04:54:50PM +0200, Ævar Arnfjörð Bjarmason wrote:
> I haven't looked at this for more than a couple of minutes (and don't
> have more time now), but this is almost certainly due to 36eba0323d
> ("repack: enable bitmaps by default on bare repos", 2019-03-14). Can you
> confirm when you re-run with repack.writeBitmaps=false in the config?
>
> I.e. something in the "yes I want bitmaps" code implies "*.keep"
> semantics changing from "keep" to "replace", which is obvious in
> retrospect, since we can only have one *.bitmap per-repo.
Yeah, the .keep behavior with bitmaps is intended, though it means a
funny implication for the bitmap-by-default strategy.
Basically, you never want to have .keep files if you have bitmaps turned
on, and so the default for "respect .keeps" is based on whether bitmaps
are in use. See ee34a2bead (repack: add `repack.packKeptObjects` config
var, 2014-03-03).
I'm not sure of the right solution. For maximal backwards-compatibility,
the default for bitmaps could become "if not bare and if there are no
.keep files". But that would mean bitmaps sometimes not getting
generated because of the problems that ee34a2bead was trying to solve.
That's probably OK, though; you can always flip the bitmap config to
"true" yourself if you _must_ have bitmaps.
-Peff
