I am happy with the results of the label experiments. (Mainly writing the tests)
>> 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.
See the new tests what I mean. It cleared up for me as well when writing them.
> I am wondering where we should sanity check (and die, pointing out
> an error in .gitattributes file). Is this function a good place to
> reject TRUE and FALSE?
TRUE and FALSE are solved issues in this series. However we still want
funny characters not be used. What if we want to use them as
special characters in the future? (e.g. 'label*' for 'labelA' or 'labelB'
or label{A,B} for the same)
I think it is too late in the matching, so ideally we would check label
names when they are assigned (i.e. while editing the .gitattributes file)
That is not in our control, though.
And during use of match_pathspec it is already to late to die(...)
for bad labels, because the labels may not be in control for the user
(She just cloned the repository and wants to inspect certain files,
which are labeled "$*&^".) So for now we just output a warning for
these cases, in the hope that content creatos upstream respect the
recommendation for labels.
Feedback welcome!
Thanks,
Stefan
Stefan Beller (5):
Documentation: fix a typo
Documentation: correct typo in example for querying attributes
pathspec: move long magic parsing out of prefix_pathspec
pathspec: move prefix check out of the inner loop
pathspec: record labels
Documentation/gitattributes.txt | 14 ++-
Documentation/glossary-content.txt | 4 +
Documentation/technical/api-gitattributes.txt | 2 +-
dir.c | 50 ++++++++
pathspec.c | 110 +++++++++++------
pathspec.h | 1 +
t/t6134-pathspec-with-labels.sh | 164 ++++++++++++++++++++++++++
7 files changed, 305 insertions(+), 40 deletions(-)
create mode 100755 t/t6134-pathspec-with-labels.sh
--
2.8.2.401.gb7348ac.dirty
--
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