Re: [PATCH v2 8/8] repack: disable writing bitmaps when doing a local geometric repack

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 4306 bytes --]

On Wed, Apr 12, 2023 at 06:01:06PM -0400, Taylor Blau wrote:
> On Wed, Apr 12, 2023 at 12:23:01PM +0200, Patrick Steinhardt wrote:
> > Now there are two different ways to fix this. The first one would be to
> > amend git-multi-pack-index(1) to disable writing bitmaps when we notice
> > that we don't have full object coverage. But we ain't really got enough
> > information there, and seeing that it is a low-level plumbing command it
> > does not feel like the right place to fix this.
> 
> I might actually advocate that we either fix this in both places, or fix
> it at the lower level only. I think that we would still be able to
> trigger this problem by invoking `git multi-pack-index write
> --bitmap --stdin-packs` directly.

The problem I see with implementing the fix is that we're just not in a
good position to judge whether we have full coverage of objects or not.
All we see is a set of packfiles, and those packfiles _could_ have full
coverage, but they may just as well not have full coverage. And whether
they do is not easy to figure out in git-multi-pack-index(1).

So in order to fix this we'd likely have to use heuristics, like whether
or not there are alternates or alternate packfiles. But unconditionally
disabling bitmaps when there are feels overly restrictive to me as it
would break perfectly-valid usecases.

I'm thus still not convinced we should implement it at the lowest level
possible. While it would be nice to deduplicate the logic around this,
I wouldn't want to close doors we don't necessarily have to.

> > ---
> >  builtin/repack.c            | 20 ++++++++++++++++++++
> >  t/t7703-repack-geometric.sh | 27 +++++++++++++++++++++++++++
> >  2 files changed, 47 insertions(+)
> >
> > diff --git a/builtin/repack.c b/builtin/repack.c
> > index f57869f14a..07d92fdf87 100644
> > --- a/builtin/repack.c
> > +++ b/builtin/repack.c
> > @@ -881,6 +881,26 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
> >  	if (pack_kept_objects < 0)
> >  		pack_kept_objects = write_bitmaps > 0 && !write_midx;
> >
> > +	if (write_midx && write_bitmaps && geometric_factor && po_args.local) {
> > +		struct packed_git *p;
> > +
> > +		for (p = get_all_packs(the_repository); p; p = p->next) {
> > +			if (p->pack_local)
> > +				continue;
> > +
> > +			/*
> > +			 * When asked to do a local repack, but we have
> > +			 * packfiles that are inherited from an alternate, then
> > +			 * we cannot guarantee that the multi-pack-index would
> > +			 * have full coverage of all objects. We thus disable
> > +			 * writing bitmaps in that case.
> > +			 */
> > +			warning(_("disabling bitmap writing, as some objects are not being packed"));
> > +			write_bitmaps = 0;
> > +			break;
> > +		}
> > +	}
> > +
> 
> In terms of the higher-level fix here, though, I think that you could
> reasonably assume that the alternate repository has at least one pack,
> and that the combination of "write_midx && write_bitmaps &&
> po.args_local" and "has any alternate(s)" is banned (or, at least, emits
> the above warning and disables writing bitmaps).
> 
> But certainly ensuring that there are indeed packs in at least one of
> the alternate(s) doesn't hurt either, so I don't mind this approach at
> all.

It's an edge case for sure. I don't quite mind which way we go either.
For now I'll just keep the current way of doing things, but am happy to
change it.

> One thing that I don't quite follow with this logic is why we need to
> have geometric_factor set. You could (somewhat unreasonably) write a
> MIDX containing a single pack (git repack -[A|a] --write-midx
> --write-bitmap-index), or a MIDX containing just the new pack along with
> all of the existing (local) packs, (git repack --write-midx
> --write-bitmap-index).
> 
> So I think we'd want to drop the geometric_factor from the above
> conditional. (And in the future, I think we typically refer to whether
> or not the "geometry" pointer is NULL or not to indicate whether or not
> we are doing a geometric repack, though the diff context doesn't give me
> enough to know whether we have even attempted to set up that instance
> yet, so this is fine, too).

Mh. Yeah, I think you're right. I'll change it.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]