git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Steadmon <steadmon@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Elijah Newren <newren@gmail.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] clone, submodule: pass partial clone filters to submodules
Date: Tue, 1 Feb 2022 13:33:25 -0800	[thread overview]
Message-ID: <YfmnJY6CMF2MP7u4@google.com> (raw)
In-Reply-To: <xmqqilu7t4nm.fsf@gitster.g>

On 2022.01.25 22:03, Junio C Hamano wrote:
> 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.

Yes, I think a new flag (and corresponding set-and-forget config option)
is the right approach. I'll include that in V2.

Out of curiosity, does the project have specific principles about
changing default behavior? For example, would it make sense to plan a
path for --this-new-flag to gradually become the default, or is that
something we'd only consider with a new major-version release?

Just thinking out loud: it should be possible for us at $job and other
people in similar situations with a managed Git installation to look
through traces and see how often people are using or not using a
particular flag or config option, and that could in theory guide such
decisions. On the other hand, I don't think that Git users at megacorps
are sufficiently representative of all Git users to be the basis for
justifying such a change, so we'd need outside feedback as well. Not
trying to suggest any particular agenda or approach here, just wondering
if others have thoughts on this topic.

  reply	other threads:[~2022-02-01 21:33 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
2022-02-01 21:33       ` Josh Steadmon [this message]
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=YfmnJY6CMF2MP7u4@google.com \
    --to=steadmon@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.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 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 NNTP newsgroup(s).