Stefan Beller <sbeller@xxxxxxxxxx> writes:
> 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'.
--
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