Subject: Re: [PATCH 03/10] builtin/pack-objects.c: learn '--assume-kept-packs-closed'

From: Taylor Blau <[email-masked]>
Date: Fri, 29 Jan 2021 17:53:58 -0500

On Fri, Jan 29, 2021 at 05:43:32PM -0500, Jeff King wrote:
> So I think the paths forward are either:
>
>   - come up with an air-tight system of making sure that we know packs
>     we claim are closed under reachability really are (perhaps some
>     marker that says "I was generated by repack -a")
>
>   - have a "roll-up" mode that does not care about reachability at all,
>     and just takes any objects from a particular set of packs (plus
>     probably loose objects)
>
> I'm still thinking aloud here, and not really sure which is a better
> path. I do feel like the failure modes for the second one are less
> risky.

The more I think about it, the more I feel that the second option is the
right approach. It seems like if you were naïvely implementing this from
scratch, that you'd pick the second one (i.e., have pack-objects
understand a new input mode, and then make a pack based on that).

I am leery that we'd be able to get the first option "right" without
attaching some sort of marker to each pack, especially given how
difficult I think that this is to reason about precisely. I suppose you
could have a .closed file corresponding to each pack, or alternatively a
$objdir/pack/pack-geometry file which specifies the same thing, but both
of these feel overly restrictive.

Besides having to special case the loose objects, is there any downside
to doing the simpler thing here?

> Anyway, here's the --unpacked example, if you're curious. It's based on
> fetching, but you could invert it to do pushes (in which case it is
> repacking in "parent" that gets the wrong result).

Fascinating indeed :-).

Thanks,
Taylor