From: Jeff Hostetler Date: Tue, 26 Sep 2017 14:03:14 GMT Subject: Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 2/3) 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: > On Fri, 22 Sep 2017 17:19:50 -0400 > Jeff Hostetler 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.) > >> FYI I just posted my RFC this afternoon. >> https://public-inbox.org/git/20170922204211.GA24036@google.com/T/ > > Thanks, I'll take a look. >