Re: [RFC PATCH] index-pack: optionally allow duplicate objects

On Wed, Jul 29, 2026 at 01:32:39PM -0700, Junio C Hamano wrote:
> Taylor Blau <[email protected]> writes:
>
> > If we can find useful ways to combine the ideas above with Git's in-tree
> > implementation of upload-pack, one could imagine that Git itself may
> > eventually send packs containing duplicate copies of some object(s)
> > behind a capability. In other words, for clients that know how to
> > process such a pack, the server may wish to ask the client to do just
> > that in the name of saving some CPU cycles necessary to generate a pack
> > that doesn't have any duplicate objects.
>
> I can live with such an extension as long as we teach the receiving
> end to deduplicate the extra copy.  Leaving packs with duplicate
> objects on disk is a completely different story, as it will become a
> source of spreading such broken packs elsewhere, though.

I am trying to nudge us in the direction of reconsidering whether a
pack containing duplicate objects *is* broken. After reading some of the
historical discussions on the list, the only "broken" portion here is
client-side support, which is what my series is trying to address.

> > But I would note that having packs containing duplicate objects is not a
> > new repository state for Git. Non-strict `index-pack` accepts duplicate
> > entries today, and shallow and filtered clones can store the same pack.
>
> The same as what???

The same pack meaning the one which contains duplicate objects. As I
understand, Friel configured clients to have a shallow depth equal to
the 32-bit unsigned maximum value (which is gross), but does cause us to
run "index-pack" without "--strict".

Thanks,
Taylor