On 2022.01.25 22:03, Junio C Hamano wrote: > Elijah Newren <newren@xxxxxxxxx> 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.
