On Mon, Apr 10, 2023 at 11:06:49AM -0400, Derrick Stolee wrote:
> On 4/5/2023 3:08 AM, Patrick Steinhardt wrote:
> > On Tue, Apr 04, 2023 at 02:55:50PM -0400, Taylor Blau wrote:
> >> On Tue, Apr 04, 2023 at 01:08:33PM +0200, Patrick Steinhardt wrote:
[snip]
> > 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 think the real bug is isolated in write_midx_included_packs() in how
> it may specify packs that the multi-pack-index cannot track. It should
> be worth the time exploring if there is an easy fix there, and then the
> po_args.local version can be used as a backup/performance tweak on top
> of that.

The problems are quite multi-faceted, but taken on their own most of the
problems actually seem quite easy to fix. I've got a local patch series
that addresses almost all of the pain points I have found until now:

- A segfault in git-multi-pack-index(1) when passed no packfiles and a
  preferred packfile that it cannot find.

- The issue that git-repack(1) asks git-multi-pack-index(1) to write an
  MIDX with packs that it cannot actually track because they are not
  local.

- An issue with git-pack-objects(1) that keeps it from packing objects
  that are non-local due to the way `--stdin-packs` is only referring to
  the packfile basenames.

- The fact that we don't honor `-l` when doing geometric repacking.

I'm still busy polishing it and finding testcases for each of these to
demonstrate the actual bugs, but will send out the series later this
week.

Patrick