From: Jeff Hostetler <git@jeffhostetler.com>
Date: Mon, 06 Nov 2017 17:32:45 GMT
Subject: Re: [PATCH 1/9] extension.partialclone: introduce partial clone extension
Message-ID: <99b7c61b-f8ab-43a0-0707-62ac1db4d080@jeffhostetler.com>
In-Reply-To: <20171103113919.396807c82dbfdecff7f19c41@google.com>



On 11/3/2017 2:39 PM, Jonathan Tan wrote:
> On Fri, 3 Nov 2017 09:57:18 -0400
> Jeff Hostetler <git@jeffhostetler.com> wrote:
> 
>> On 11/2/2017 6:24 PM, Jonathan Tan wrote:
>>> On Thu,  2 Nov 2017 20:20:44 +0000
>>> Jeff Hostetler <git@jeffhostetler.com> wrote:
>>>
>>>> From: Jeff Hostetler <jeffhost@microsoft.com>
>>>>
>>>> Introduce the ability to have missing objects in a repo.  This
>>>> functionality is guarded by new repository extension options:
>>>>       `extensions.partialcloneremote` and
>>>>       `extensions.partialclonefilter`.
>>>
>>> With this, it is unclear what happens if extensions.partialcloneremote
>>> is not set but extensions.partialclonefilter is set. For something as
>>> significant as a repository extension (which Git uses to determine if it
>>> will even attempt to interact with a repo), I think - I would prefer
>>> just extensions.partialclone (or extensions.partialcloneremote, though I
>>> prefer the former) which determines the remote (the important part,
>>> which controls the dynamic object fetching), and have another option
>>> "core.partialclonefilter" which is only useful if
>>> "extensions.partialclone" is set.
>>
>> Yes, that is a point I wanted to ask about.  I renamed the
>> extensions.partialclone that you created and then I moved your
>> remote.<name>.blob-max-bytes setting to be in extensions too.
>> Moving it to core.partialclonefilter is fine.
> 
> OK - in that case, it might be easier to just reuse my first patch in
> its entirety. "core.partialclonefilter" is not used until the
> fetching/cloning part anyway.
> 

Good point.  I'll take a look at refactoring that.
If it looks like the result will be mostly/effectively
your original patches, I'll let you know and hand part 2
back to you.

> I agree that "core.partialclonefilter" (or another place not in
> "remote") instead of "remote.<name>.blob-max-bytes" is a good idea - in
> the future, we might want to reuse the same filter setting for
> non-fetching functionality.
> 

Jeff