Junio C Hamano <gitster@xxxxxxxxx> writes: > "Nikolay Edigaryev via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > >> 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. > ... > But a bundle that were created with objects _omitted_ already? > ... the source of this clone operation, i.e. the bundle file that is > pointed at by "remote.$remote_name.url", cannot be that promisor. Extending the above a bit, one important way a bundle is used is as a medium for sneaker-net. Instead of making a full clone over the network, if you can create a bundle that records all objects and all refs out of the source repository and then unbundle it in a different place to create a repository, you can tweak the resulting repository by either adding a separete remote or changing the remote.origin.url so that your subsequent fetch goes over the network to the repository you took the initial bundle from. The "tweak the resulting repository" part however MUST be done manually with the current system. If we can optionally record the publically reachable URL of the source repository when we create a bundle file, and "git clone" on the receiving side can read the URL out of the bundle and act on it (e.g., show it to the user and offer to record it as remote.origin.url in the resulting repository---I do not think it is wise to do this silently without letting the user know from security's point of view), then the use of bundle files as a medium for sneaker-netting will become even easier. And once that is done, perhaps allowing a filtered bundle to act as a sneaker-net medium to simulate an initial filtered clone would make sense. The promisor as well as the origin will be the network reachable URL and subsequent fetches (both deliberate ones via "git fetch" as well as lazy on-demand ones that backfills missing objects via the "promisor" access) would become possible. But without such a change to the bundle file format, allowing "clone" to finish and pretend the resulting repository is usable is somewhat irresponsible to the users. The on-demand lazy fetch would fail after this code cloned from such a filtered bundle, no?