From: Jeff Hostetler <git@jeffhostetler.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, gitster@pobox.com, peff@peff.net,
Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH 1/9] extension.partialclone: introduce partial clone extension
Date: Fri, 3 Nov 2017 09:57:18 -0400 [thread overview]
Message-ID: <1db01a45-85c4-6243-c43f-9f5e50e9a6a8@jeffhostetler.com> (raw)
In-Reply-To: <20171102152427.32544b3d6149e7a7bfe840c8@google.com>
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.
>
> I also don't think extensions.partialclonefilter (or
> core.partialclonefilter, if we use my suggestion) needs to be introduced
> so early in the patch set when it will only be used once we start
> fetching/cloning.
>
>> +void partial_clone_utils_register(
>> + const struct list_objects_filter_options *filter_options,
>> + const char *remote,
>> + const char *cmd_name)
>> +{
>
> This function is useful once we have fetch/clone, but probably not
> before that. Since the fetch/clone patches are several patches ahead,
> could this be moved there?
Sure.
>
>> @@ -420,6 +420,19 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
>> ;
>> else if (!strcmp(ext, "preciousobjects"))
>> data->precious_objects = git_config_bool(var, value);
>> +
>> + else if (!strcmp(ext, KEY_PARTIALCLONEREMOTE))
>> + if (!value)
>> + return config_error_nonbool(var);
>> + else
>> + data->partial_clone_remote = xstrdup(value);
>> +
>> + else if (!strcmp(ext, KEY_PARTIALCLONEFILTER))
>> + if (!value)
>> + return config_error_nonbool(var);
>> + else
>> + data->partial_clone_filter = xstrdup(value);
>> +
>> else
>> string_list_append(&data->unknown_extensions, ext);
>> } else if (strcmp(var, "core.bare") == 0) {
>
> With a complicated block, probably better to use braces in these
> clauses.
>
Good point.
Thanks,
Jeff
next prev parent reply other threads:[~2017-11-03 13:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-02 20:20 [PATCH 0/9] WIP Partial clone part 2: fsck and promisors Jeff Hostetler
2017-11-02 20:20 ` [PATCH 1/9] extension.partialclone: introduce partial clone extension Jeff Hostetler
2017-11-02 22:24 ` Jonathan Tan
2017-11-03 13:57 ` Jeff Hostetler [this message]
2017-11-03 18:39 ` Jonathan Tan
2017-11-06 17:32 ` Jeff Hostetler
2017-11-06 19:16 ` Jonathan Tan
2017-11-08 20:32 ` Jeff Hostetler
2017-11-08 21:51 ` Jonathan Tan
2017-11-08 22:11 ` Jeff Hostetler
2017-11-16 17:33 ` Jeff Hostetler
2017-11-02 20:20 ` [PATCH 2/9] fsck: introduce partialclone extension Jeff Hostetler
2017-11-02 20:20 ` [PATCH 3/9] fsck: support refs pointing to promisor objects Jeff Hostetler
2017-11-02 20:20 ` [PATCH 4/9] fsck: support referenced " Jeff Hostetler
2017-11-02 20:20 ` [PATCH 5/9] fsck: support promisor objects as CLI argument Jeff Hostetler
2017-11-02 20:20 ` [PATCH 6/9] index-pack: refactor writing of .keep files Jeff Hostetler
2017-11-02 20:20 ` [PATCH 7/9] introduce fetch-object: fetch one promisor object Jeff Hostetler
2017-11-02 20:20 ` [PATCH 8/9] sha1_file: support lazily fetching missing objects Jeff Hostetler
2017-11-02 20:20 ` [PATCH 9/9] gc: do not repack promisor packfiles Jeff Hostetler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1db01a45-85c4-6243-c43f-9f5e50e9a6a8@jeffhostetler.com \
--to=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jeffhost@microsoft.com \
--cc=jonathantanmy@google.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).