Stefan Beller <sbel...@google.com> writes: > We can still keep the submodule.defaultGroup. (In the WIP I renamed > it to updateGroup as its only feature is to have it set during clone > and remebered for `git submodule update`)
Yes, my idle speculation between "[submodule"x"] label=A" stored in .gitmodules and "path/to/submodule group=A" in .gitattributes is completely orthogonal to the need for submodule.defaultGroup. The only difference it brings in is how we evaluate what submodule.defaultGroup names (i.e. via "submodule label" vs "path label"). > When we allow labels to be generic path labels instead of submodule > labels, the user might be tempted to ask, why the submodules can > be specified but not the individual paths, i.e. > > git clone --init-submodule="(:group=docs)" ... > > may strongly hint at: > > git clone --narrow="(:group=docs)" ... > > would only get parts of the repository. If we are to have a (proper) narrow clone, I do not think there is any reason why the latter should not work as expected. > For the submodule case, this may add confusion as the user would > need to configure some properties in the .gitmodules file and some > in the .gitattributes file. I do not quite understand this comment. A new reader who knows nothing about "grouping submodules" would not have any trouble, I suspect, if all and the only grouping she learns is "grouping paths" from the beginning. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
