Stefan Beller <sbeller@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html