Re: [PATCH 0/7] submodule groups

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2016, 16:53 UTC
Message-ID: <xmqqzirvfca5.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kZHbAiP13rC+VLnFUtoxPZEcyx_wkrxfKb+cGBxQaojZQ@mail.gmail.com>

Stefan Beller <sbeller@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").

Show 11 quoted lines

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