Stefan Beller <sbel...@google.com> writes: >> Then while parsing ":(attr:VAR1=VAL1 -VAR2 VAR3...)path/to/dir/", > > This syntax is not pleasant to parse IMHO as it is not clear if the token > after white space (-VAR2 here) is another attribute or the next part of > the list of VAR1, ...
Remove the ambiguity by declaring that the list is always whitespace separated. No whitespace in var, no whitespace in val, no quoting. The set of attributes with values expected to be used in the pathspec "attribute match" magic, I do not think there is anything that wants such a random arbitrary string. The value side of an attribute with value, e.g. "eol=crlf", "conflict-marker-size=7", is designed to be a token that our C code is prepared to parse. In other words, if you match the parsing semantics of parse_attr() in attr.c, you are OK. The attribute subsystem will not give users anything that is more complex than what that routine is prepared to parse, and that is a "whitespace separated list, no whitespace in attribute names, no whitespace in values, no quoting". -- 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
