Re: [PATCH 0/7] submodule groups
From: Junio C Hamano <hidden>
Date: 2016-06-16 02:19:20
Stefan Beller [off-list ref] writes:
If you have lots of submodules, you probably don't need all of them at once, but you have functional units. Some submodules are absolutely required, some are optional and only for very specific purposes. This patch series adds labels to submodules in the .gitmodules file.
I hate to bring this up in this thread, primarily because I cannot
see how to make it mesh well with the "submodule spec lets you
specify a group of submodule with labels", but for completeness of
discussion, I'll mention it anyway.
Instead of specifying "all files written in Perl" to work on by
giving a pathspec with three elements, e.g.
git cmd -- \*.perl \*.pl \*.pm
I've often wondered if it would be a good idea to let attributes
file to specify "these paths form the group Perl" with something
like:
*.pm group=perl
*.pl group=perl
*.perl group=perl
*.h group=c
*.c group=c
and say
git cmd -- ':(group=perl)'
instead.
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.