Re: [PATCH] send-pack.c: add config push.useBitmaps

From: Taylor Blau <me@ttaylorr.com>
Date: Jun 15, 2022, 21:32 UTC
Message-ID: <YqpP0b2zt0sWZD0B@nand.local>
In-Reply-To: <220615.86edzpy9m6.gmgdl@evledraar.gmail.com>

On Wed, Jun 15, 2022 at 09:47:58PM +0200, Ævar Arnfjörð Bjarmason wrote:

> Refresh my memory, we always use them if we find them now, correct?
> I.e. if repack.writebitmaps=true

Kind of. `rev-list` has an opt-in `--use-bitmap-index` option, and `pack-objects` has `pack.useBitmaps` which controls whether or not bitmaps are read.

So `git rev-list --objects HEAD` won't use any bitmaps, even if they exist, but `git rev-list --objects --use-bitmap-index HEAD` will. There there's a good reason not to use bitmaps by default, which is that they (effectively) randomize the ordering of your output.

`pack-objects` behaves slightly differently, cf. its `use_bitmap_index{,default}` variables to see how that works.

Show 6 quoted lines

> This doesn't make it clear: Are we now going to ignore them for "push"
> by default, even if they exist? I.e. a change in the current default.
>
> I think I recall from the previous discussions that it was a bit of hit
> & miss, maybe we're confident that they're almost (or always?) bad for
> "push", but I think there *are* cases where they help.

Yeah. In theory they should help most of the time as long as the bitmaps are kept reasonably up-to-date. There's a tradeoff between using bitmaps and how much walking between bitmap and ref-tips is required. Since every object we encounter between the most recent bitmap and the thing we're trying to generate a bitmap for has to incur extra overhead in order to find and mark its position in the bitmap being generated, there's a certain point at which it would have been faster to just walk down to the roots and avoid bitmaps altogether.

But I suspect that in this case the bitmaps are just simply stale, and that a "git repack -adb" or more aggressive background maintenance would make things quite a bit faster.

Thanks, Taylor