Re: Proposal: object negotiation for partial clones

From: Matthew DeVore <matvore@comcast.net>
Date: May 7, 2019, 21:57 UTC
Message-ID: <A0ADEE11-E3E1-4DE0-81BA-40771C783E4E@comcast.net>
In-Reply-To: <20190507183450.50568-1-jonathantanmy@google.com>

Show 10 quoted lines

> On 2019/05/07, at 11:34, Jonathan Tan <jonathantanmy@google.com> wrote:
> 
> 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"?

I am interested in supporting large repositories. The savings seem to be larger than one may expect. I tried the following command on two huge repos to find out how much it costs to fetch “blob:none” for a single commit:

$ git rev-list --objects --filter=blob:none HEAD: | xargs -n 2 bash -c 'git cat-file -s $1' | awk '{ total += $1; print total }'

Note the “:” after HEAD - this limits it to the current commit.

And the results were:
 - Linux: 2 684 054 bytes
 - Chromium: > 16 139 570 bytes (then I got tired of waiting for it to finish)