On Mon, May 16, 2016 at 2:18 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> This is another case for using ':' instead of '='. >> So I think ':' is better for this future enhancement. >> >> Also this future enhancement may ask for >> >> git ls-files ":(attr:label=foo)" >> >> or >> >> git ls-files ":(attr:-label)" >> >> so the user can circumvent the warn and ignore strategy. :( > > That is exactly what we want, I would say, if we want to accept > "arbitrary set of attributes with their states". > > The "warn and ignore" comes only from "with '(:label=X Y Z)', we > inspect attributes X, Y and Z and insist them to be set to true; it > is a configuration error to set the label to anything but a string", > and accepting "arbitrary set of attributes with their states" makes > it moot (as I said earlier in $gmane/294776). > > So are we leaning towards ":(attr:<state>)", where <state> is one of > > var=value > var > -var > !var > > now? It makes the pathspec magic parser a bit more complex (and I > am not sure if we have to worry too much about quoting "value" part > to allow arbitrary sequence of bytes), though. And we want to have both "label=A B C" and attr:label=A B C" or *just* the attr query? We should not allow the user to add arbitrary attributes (i.e. labels). Instead each of the "attr for labeling purposes" needs to follow a clear scheme that allows us to add attributes later on that are outside of that scheme. In a very first implementation we could require the attribute to start with "label=". ;) -- 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