Re: [PATCH] repack: fix geometric repacking with gitalternates

[Taylor Blau <me@ttaylorr.com>]

On Wed, Apr 05, 2023 at 09:08:19AM +0200, Patrick Steinhardt wrote:
> But I'm not yet sure whether I understand why `-l --write-midx` should
> be prohibited like you summarized in the follow-up mail:
>
> On Tue, Apr 04, 2023 at 02:55:50PM -0400, Taylor Blau wrote:
> > TL;DR: I think that this is a (much) more complicated problem than
> > originally anticipated, but the easiest thing to do is to assume that
> > git repack --geometric=<d> means git repack --geometric=<d> --no-local
> > unless otherwise specified, and declare --geometric=<d> --local
> > unsupported when used in conjunction with --write-midx or
> > --write-bitmap-index.
>
> The newly written MIDX would of course only span over the local
> packfiles, but is that even a problem? Ideally, Git would know to handle
> multiple MIDX files, and in that case it would make sense both for the
> shared and for the member repository to have one.

Right, I don't think that it's a problem. But I don't know how well the
MIDX-over-alternates thing works in practice. I know that the feature
exists, but I don't think it is as battled-tested as non-alternated
MIDXs.

So I think you'd have to ban MIDX bitmaps when the MIDX spans over
multiple repositories through an alternates file, but otherwise it
should be OK.

> But that raises the question: what do we do about the currently-broken
> behaviour when executing `git repack --geometric=<d> --no-local` in a
> alternated repository?
>
> I'd personally be fine to start honoring the `po_args.local` flag so
> that we skip over any non-local packfiles there while ignoring the
> larger problem of non-local geometric repacks breaking in certain
> scenarios. It would at least improve the status quo as users now have a
> way out in case they ever happen to hit that error. And it allows us to
> use geometric repacks in alternated repositories. But are we okay with
> punting on the larger issue for the time being?

I wonder if the larger issue could be simplified into (a) honoring
`po_args.local` when doing the geometric rollup, and (b) dropping the
non-local packs when writing a MIDX.

> Thanks for your feedback and this interesting discussion!

Ditto ;-).

Thanks,
Taylor