Re: Proposal: object negotiation for partial clones

From: Jonathan Tan <jonathantanmy@google.com>
Date: May 7, 2019, 18:34 UTC
Message-ID: <20190507183450.50568-1-jonathantanmy@google.com>
In-Reply-To: <CAMfpvh+jbPcU2waU5n6nToxGEsC29WGOFPLR+ibXbhXL6WBb6w@mail.gmail.com>

Show 11 quoted lines

> > My main question is: we can get the same list of objects (in the form of
> > tree objects) if we fetch with "blob:none" filter. Admittedly, we will
> > get extra data (file names, etc.) - if the extra bandwidth saving is
> > necessary, this should be called out. (And some of the savings will be
> > offset by the fact that we will actually need some of those tree
> > objects.)
> That's a very good point. The data the first request gives us is
> basically the tree objects minus file names and modes. So I think a
> better feature to implement would be combining of multiple filters.
> That way, the client can combine "tree:<some small number>" and
> "blob:none" and basically get an "enumeration" of available objects.

To get an enumeration of available objects, don't you need to use only "blob:none"? Combining filters (once that's implemented) will get all objects only up to a certain depth.

Combining "tree:<n>" and "blob:none" would allow us to reduce the number of trees transmitted, but I would imagine that the savings would be significant only for very large repositories. Do you have a specific use case in mind that isn't solved by "blob:none"?