Re: [RFC PATCH 0/4] pathspec labels [WAS: submodule groups]

From: Stefan Beller <sbeller@google.com>
Date: May 16, 2016, 21:36 UTC
Message-ID: <CAGZ79kZuMdWdw2kcfs_P-_Ax1zXpKNHqMjNL80hBj3=SSp2zSQ@mail.gmail.com>
In-Reply-To: <xmqqlh391z2v.fsf@gitster.mtv.corp.google.com>

On Mon, May 16, 2016 at 2:18 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 34 quoted lines

> Stefan Beller <sbeller@google.com> 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=". ;)