Re: [PATCH] clone, submodule: pass partial clone filters to submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2022, 06:03 UTC
Message-ID: <xmqqilu7t4nm.fsf@gitster.g>
In-Reply-To: <CABPp-BE2B9NkWG8bWft6m-UOg66aRpjwSRTWvAyrKCiwJCemHQ@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 6 quoted lines

> But how would that interact with this patch?  There's a bit of a
> conflict.  There's a few ways out:
>   * Make your change be explicit rather than implicit: Based on
> Junio's first concern, you could modify this patch so that it requires
> a new flag like --filter-submodules-too (or some better name), and
> perhaps folks with a path filter just wouldn't use that.

I would very much prefer this, given that this is a change of default proposed by those who want a different default than the status quo, even without the "how would we know it is sensible to just pass down any and all filters?" issue.

>   * Make these incompatible: Maybe a path filter is incompatible with
> --recurse-submodules, and we should throw an error if both are
> specified.

Perhaps. Or automatically filter out such an incompatible ones, but of course, that would mean submodules are made less filtered than top-level which is usually the other way around.

Show 6 quoted lines

>   * Attempt to marry the two options: Each submodule could perhaps
> extract the subset of paths with itself as a leading directory and
> remove that leading prefix and then use that as the path portion of
> the filter.  (And perhaps even taking this a step farther: each level
> of cloning will only recurse into submodules which match the specified
> paths).

Yup, for some filters, passing them down may have a "natural" translation, similar to adding the prefix to a pathspec element. It would probably depend on the filter if there is such a natural translation even exists, though.