Re: [PATCH 0/7] submodule groups

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2016, 15:58 UTC
Message-ID: <xmqqoa8bgten.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq37pnj04f.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 11 quoted lines

> The reason why I suspect that this may not work well with submodule
> labels is because submodule labels (or any attribute we give via
> .gitmodules to a submodule) are keyed by a submodule name, which is
> the primary unchanging key (so that people can "mv" a submodule in
> the context of the toplevel superproject without losing track of
> submodule identity), not by paths to submodules, while the "group"
> thing I want is merely a short-hand for pathspec elements and wants
> to be keyed by paths.
>
> But there may be somebody more clever than I who can come up with a
> way to unify these two similar concepts without confusing end users.

Thinking about this even more, if there is no requirement that labels must be tied to submodule names, we just can scrap the idea of "submodule labels" to group things and instead just use "path labels", i.e. write the full path to the submodule and assign it a label in .gitattributes and use it in place of where we used *label in the patch series. After all, an easy way to choose some among many submodules logically is a subset of an easy way to choose some among many paths.

The only reason why we added the submodule label to .gitmodules is because we viewed it as submodule-specific thing and the "keyed by name, not path" came as a consequence, not because any real "we must key it by name because..." reason, I would think.

I know this is a huge departure from the design presented both at the conceptual level and also at the implementation level, and that is one of the reasons why I do not particularly want to like it, but on the other hand, I am not bold enough to say that I will have a good answer when later somebody asks "Why can we group only submodules with labels, but not random group of paths (e.g. 'these directories are about documentation')?" And then, if we add path labels to allow expressing groups of paths later, the follow-up question would be "When should I use submodule labels and when should I use path labels? I can use path labels to group submodules and say 'git submodule update -- :(group=docs)' can't I?".

And that makes me pause and step back from the "submodule labels" idea.