Re: [PATCH 0/7] submodule groups

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2016, 00:00 UTC
Message-ID: <xmqqd1osi1r8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kY3S6SmJOMQ7RAKw0yTvicY=Y1VRRGdm5uK9+Eb7W+Ykg@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 5 quoted lines

>     git submodule--helper matches-submodulespec sub0 ./.
> ./:(exclude)*0 *label-sub0
>
> which should test if the first argument (sub0) matches the submodulespec
> which follows.

This, according to that "OR'ed together" definition, asks to find a submodule

    - whose path matches pathspec ./. ./:(exclude)*0; or
    - is labeled with label-sub0.

So I'd say it is natural sub0 matches if its path is at sub0 and has a label label-sub0.

You could instead choose to use "AND'ed together" semantics, but that would break expectation by those who expect "This OR that" behaviour. Unless you are willing to support --and/--or/(/) like "git grep" does to express a way to combine hits from individual terms, that is an inherent limitation.

I'd suggest not to over-engineer this. Go back and imagine how "/bin/ls" would work is a good sanity check to gauge what complexity levels ordinary users would feel comfortable to handle.

"ls a b" would give union of what "ls a" and "ls b" would output, there is no negation, and the users won't die from having to say "ls [A-Za-qs-z]*" to exclude files whose names begin with 'r'.