Stefan Beller <sbeller@xxxxxxxxxx> writes: >> Ah, of course. I thought that you were trying to limit ":(attr:<attribute>)" >> magic only to attributes that begin with "label-", which is where my >> "why not?" comes from. > > And going by the logic you presented before, we would > need to error out for the given pathspec ":(<string>)" if > > * either the string is not well known (e.g. diif, eol ) > * or is outside of the labeling namespace. I do not think that follows _my_ line of thought. What is "well known"? Doesn't that change over time? If we are to do the "attribute match", there is no useful enforcement point. An arbitrary version of Git cannot differentiate a random cruft users will write in their .gitattributes from a legitimate attribute that will be introduced in the future, so both "data in .gitattributes" and "pathspec magic that referes to attribute" cannot be limited by us. So if we are going to take the arbitrary ":(attr:<attribute>)" route, "label-" prefix would be limitation on the "core Git" side and does not limit what end-user does. We will promise that we won't use names that begin with the prefix ourselves and leave them up to the projects. If the end user uses an attribute "foo", which does not begin with "label-", the end user is risking to be broken by future versions of Git. If you want to compile an authoritative list of attributes used by core Git and maintain it forever, you are welcome to add warning, but I wouldn't bother if I were doing this series, at least at the beginning. -- 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