git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

  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).