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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).