Re: [PATCH 0/7] submodule groups

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2016, 05:50 UTC
Message-ID: <xmqq37pnj04f.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1462928397-1708-1-git-send-email-sbeller@google.com>

Stefan Beller <sbeller@google.com> writes:

Show 5 quoted lines

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