Stefan Beller <sbel...@google.com> writes:
> I am not talking about crazy stuff here, but consider our own
> .gitattributes file:
>
> * whitespace=!indent,trail,space
> *.[ch] whitespace=indent,trail,space
> *.sh whitespace=indent,trail,space
>
> Now I want to search for
>
> "the whitespace attribute that is set to at least trail and space"
With :(attr:VAR=VAL) syntax, you can only look for whitespace
attribute exactly set to "!indent,trail,space", so you can't. So
you are talking about crazy stuff after all, aren't you? Are you
now extending it to do "whitespace~=indent" or something like that?
You do not even need VAR=VAL form for your main topic. You only
need group-doc group-code etc. to look for "set to TRUE", no?
I do not want to see us wasting too much time over-engineering it
without having a concrete and useful use case, and "find path to
whom whitespace checks are set for 'trail' and 'space'" is not.
These comma-separated tokens augment WS_DEFAULT_RULE which has
'trail' already, so you do not look for 'trail' in the first place.
"I want submodules under subs/ that is in either group-doc or
group-code" is more reasonable and realistic use case, but that does
not need any crazy stuff. Either two separate pathspec elements,
":(attr:group-doc)subs/" ":(attr:group-code)/subs/"
or if we are to do the "ORed collection of ANDed attrs", it would be
something like:
":(attr:group-doc):(attr:group-code)/subs/"
no?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
