Re: [PATCH v2 0/4] [RFC] repack: add --filter=

From: Taylor Blau <me@ttaylorr.com>
Date: Feb 22, 2022, 19:35 UTC
Message-ID: <YhU7BK5uOS5OK/ZB@nand.local>
In-Reply-To: <CFECF0B1-A94F-4372-AFC9-C0469A17E9A5@gmail.com>

On Tue, Feb 22, 2022 at 01:52:09PM -0500, John Cai wrote:

Show 8 quoted lines

> > Another option would be to prune the repository according to objects
> > that are already made available by a promisor remote.
>
> Thanks for the discussion around the two packfile idea. Definitely
> interesting.  However, I'm leaning towards the second option here
> where we ensure that objects that are about to be deleted can be
> retrieved via a promisor remote. That way we have an easy path to
> recovery.

Yeah, I think this may have all come from a potential misunderstanding I had with the original proposal. More of the details there can be found in [1].

But assuming that this proposal isn't about first offloading some objects to an auxiliary (non-Git) server, then I think refiltering into a single pack makes sense, because we trust the remote to still have any objects we deleted.

(The snag I hit was that it seemed like your+Christian's proposal hinged on using _two_ filters, one to produce the set of objects you wanted to get rid of, and another to produce the set of objects you wanted to keep. The lack of cohesion between the two is what gave me pause, but it may not have been what either of you were thinking in the first place).

Anyway, I'm not sure "spitting" a repository along a `--filter` into two packs is all that interesting of an idea, but it is something we could do if it became useful to you without writing too much new code (and instead leveraging `git pack-objects --stdin-packs`).

Thanks, Taylor

[1]: https://lore.kernel.org/git/YhUeUCIetu%2FaOu6k@nand.local/