From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Josh Steadmon <steadmon@google.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] clone, submodule: pass partial clone filters to submodules
Date: Tue, 25 Jan 2022 22:03:25 -0800 [thread overview]
Message-ID: <xmqqilu7t4nm.fsf@gitster.g> (raw)
In-Reply-To: CABPp-BE2B9NkWG8bWft6m-UOg66aRpjwSRTWvAyrKCiwJCemHQ@mail.gmail.com
Elijah Newren <newren@gmail.com> writes:
> 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.
> * 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.
next prev parent reply other threads:[~2022-01-26 6:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-21 3:32 [PATCH] clone, submodule: pass partial clone filters to submodules Josh Steadmon
2022-01-22 1:49 ` Junio C Hamano
2022-01-25 21:00 ` Elijah Newren
2022-01-26 6:03 ` Junio C Hamano [this message]
2022-02-01 21:33 ` Josh Steadmon
2022-01-25 21:08 ` Elijah Newren
2022-02-01 21:34 ` Josh Steadmon
2022-02-05 0:40 ` [PATCH v2] " Josh Steadmon
2022-02-05 0:54 ` Josh Steadmon
2022-02-05 1:00 ` Josh Steadmon
2022-02-05 5:00 ` [PATCH v3] " Josh Steadmon
2022-02-09 22:44 ` Jonathan Tan
2022-02-09 23:37 ` Junio C Hamano
2022-02-19 17:30 ` [PATCH] t5617,t7814: remove unnecessary 'uploadpack.allowanysha1inwant' Philippe Blain
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=xmqqilu7t4nm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=steadmon@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.