Re: [PATCH 4/4] pathspec: record labels

From: Junio C Hamano <gitster@pobox.com>
Date: May 13, 2016, 06:28 UTC
Message-ID: <xmqqtwi2a2v6.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbaqw9UvYrCWcLtAXaiw5-aSev9gn858zz5Ju0MVfzepQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

> Would it make sense to mark a file as
>
>     "follows the labeling system, but has no label" (TRUE)
>     "doesn't follow the labeling system at all" (FALSE)

Isn't the former be "label="

I do not know what you mean by the latter. I would understand "pretend this has all the labels under the sun", though.

Show 9 quoted lines

>>     Ahh, you are making ":(label=...)makefile" to say "paths must
>>     match the string 'makefile' in some way, and further the paths
>>     must have all these labels?  Then falling through is correct.
>
> This is how I understood your initial design idea.
>
>     :(label=C_code)contrib/
>
> gives all the retired C programs.

OK, you probably meant s/C program/shell script/ with a different label, but I think I got the idea.

> I wonder that you focus on the details already, but not on the grand
> design of things. "Is it actually a sane thing I am proposing here?"
> Though you may be biased as the the high level idea came from
> you. :)

Biased is the primary reason ;-) I trust that other reviewers can stop me and correct course when I veer off the deep end by myself.

Just like you called this as a "mock", I am treating this as a testbed to let you try out the "defaultGroup" thing to see how flexibly you can express common wishes the end users have, i.e. "does it give us an expressive enough system to replace repo?" is the question I want this code to help answering. And that is why I was trying to make sure it is good enough quickly.

> One of the things I switched last minute and tried to address in
> the cover letter is the semantics of ORing or ANDing the labels
> given within one pathspec item.

That is something we may find out that the other way is more useful, or your final choice is better, by seeing how easy to express common patterns of submodule selections. Perhaps we might end up wanting both, but as you said, OR can be given by listing the same path with differnt required-labels so I think what you have is good enough for us to start experimenting with the higher layer.

One worry I have is that historically pathspec matching and attribute matching have both been very hard to make it perform well. The placement of string_list_has_string() and load_labels() at the leaf level of the pathspec matching logic cannot be helped, but these calls might turn out to be an unacceptable performance bottleneck. But it is a bit too early to worry about that, I think.