Stefan Beller <sbeller@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html