Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 2/3)

From: Jeff Hostetler <git@jeffhostetler.com>
Date: Sep 26, 2017, 14:03 UTC
Message-ID: <4cc2e996-250d-c62c-905d-b75467d7fe09@jeffhostetler.com>
In-Reply-To: <20170922155235.7b50de91f0370d9101cc4faa@google.com>

On 9/22/2017 6:52 PM, Jonathan Tan wrote:

Show 20 quoted lines

> On Fri, 22 Sep 2017 17:19:50 -0400
> Jeff Hostetler <git@jeffhostetler.com> wrote:
> 
>>> In your specific example, how would rev-list know, on the client, to
>>> include (or exclude) a large blob in its output if it does not have it,
>>> and thus does not know its size?
>>>
>>
>> The client doesn't have the size. It just knows it is missing and it
>> needs it. It doesn't matter why it is missing.  (But I guess the client
>> could assume it is because it is large.)
> 
> Ah, OK.
> 
>> So rev-list on the client could filter the objects it has by size.
> 
> My issue is that if the purpose of this feature in rev-list is to do
> prefetching, the only criterion we need to check for is absence from the
> local repo right? (Or is filtering by size on the client useful for
> other reasons?)

The prefetch before a checkout may want all missing blobs, or it want to work with the sparse-checkout specification and only get the required missing blobs in the subset of the tree. By putting the same filter logic in rev-list, we can do that.

It also sets the stage for later filtering trees. (My current patch only filters blobs. It would be nice to have a second version of the sparse filter that also omits trees, but that may require a recursive option in the fetch-objects protocol.)

Show 6 quoted lines

> 
>> FYI I just posted my RFC this afternoon.
>> https://public-inbox.org/git/20170922204211.GA24036@google.com/T/
> 
> Thanks, I'll take a look.
>