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

From: Josh Steadmon <[email-masked]>
Date: Tue, 1 Feb 2022 13:33:25 -0800

On 2022.01.25 22:03, Junio C Hamano wrote:
> Elijah Newren <[email-masked]> 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.