git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] clone: support cloning of filtered bundles

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 15, 2024, 01:13 UTC
Message-ID
<xmqqcyu35rg9.fsf@gitster.g>
In-Reply-To
<pull.1644.git.git.1705231010118.gitgitgadget@gmail.com>

"Nikolay Edigaryev via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 19 quoted lines
> diff --git a/builtin/clone.c b/builtin/clone.c
> index c6357af9498..4b3fedf78ed 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -1227,9 +1227,18 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>  
>  		if (fd > 0)
>  			close(fd);
> +
> +		if (has_filter) {
> +			strbuf_addf(&key, "remote.%s.promisor", remote_name);
> +			git_config_set(key.buf, "true");
> +			strbuf_reset(&key);
> +
> +			strbuf_addf(&key, "remote.%s.partialclonefilter", remote_name);
> +			git_config_set(key.buf, expand_list_objects_filter_spec(&header.filter));
> +			strbuf_reset(&key);
> +		}
> +
> -# NEEDSWORK: 'git clone --bare' should be able to clone from a filtered
> -# bundle, but that requires a change to promisor/filter config options.

Sorry, but this "should be able to" does not make sense to me in the first place.

I can understand how an operation to create a narrow clone of an unfiltered bundle and then prepare the resulting repository for future "fattening" by naming the unfiltered bundle file a "promisor", and allow the user to lazily fetch objects that have initially been filtered out of the bundle lazily.

But a bundle that were created with objects _omitted_ already? It obviously cannot "promise" to deliber any objects that ought to be reachable from the objects contained in it, so setting the bundle file as promisor in the configuration does not help the resulting repository. Those missing objects must be obtained from somewhere other than that original "filtered" bundle, and if that source of objects that can promise all the objects that are ought to be reachable were specified as the promisor, it would make sense. But the source of this clone operation, i.e. the bundle file that is pointed at by "remote.$remote_name.url", cannot be that promisor.

Previous: phillip.wood123@gmail.comNext: Junio C Hamano
Message 7 of 9 in “clone: support cloning of filtered bundles”
  1. clone: support cloning of filtered bundlesNikolay Edigaryev via GitGitGadget, Jan 14, 2024
  2. Phillip WoodJan 14, 2024
  3. Nikolay EdigaryevJan 14, 2024
  4. Nikolay EdigaryevJan 14, 2024
  5. phillip.wood123@gmail.comJan 15, 2024
  6. phillip.wood123@gmail.comJan 15, 2024
  7. Junio C HamanoJan 15, 2024
  8. Junio C HamanoJan 15, 2024
  9. Nikolay EdigaryevJan 16, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.