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