This goes on top of origin/jc/attr, (8195c5cde01, SQUASH???, 2016-05-17 14:08:50)
Patches 1 and 2 are small fixes, which could go independently as well.
(1 is new compared to v6)
Patches 3 and 4 are refactoring pathspec.c a little.
The last patch is the most exciting patch as it adds the new feature.
Quoting from the documentation update:
attr;;
Additionally to matching the pathspec, the path must have the
attribute as specified. The syntax for specifying the required
attributes is "`attr: [mode] <attribute name> [=value]`"
+
Attributes can have 4 states (Set, Unset, Set to a value, unspecified) and
you can query each attribute for certain states. The "`[mode]`" is a special
character to indicate which attribute states are looked for. The following
modes are available:
- "`+`" the attribute must be set
- "`-`" the attribute must be unset
- "`~`" the attribute must be unspecified
- "`?`" the attribute must not be unspecified, i.e. set, unset or value matches
- an empty "`[mode]`" matches if the attribute is set or has a value
- an empty "`[mode]`" combined with "`[=value]`" matches if the attribute has
the given value.
+
While I followed Junios suggestion of the data layout in pathspec.h,
I am not quite happy with it yet as I think it will not be easy in the future
to enhance search for specific attribute values. Quoting from the tests:
test_expect_success 'check label with 2 labels' '
cat <<EOF >expect &&
fileAB # has both labels
sub/fileAB # has both labels
EOF
git ls-files ":(attr:labelA labelB)" >actual &&
test_cmp expect actual &&
git ls-files ":(attr:labelA,attr:labelB)" >actual &&
test_cmp expect actual
'
You can see that two notations are possible to narrow the search down when
asking for 2 attributes to be set. Either you can do 2 "attr:" magic strings
or you can have one "attr:" and then a space separated list of attributes.
The problem arises once you'd want to have a better search for values, as
currently only ":(attr:label=value) is supported with "value" being the
exact match, e.g. a path having more than just value would not match as it is
not exact. E.g. in git.git we have
$ cat .gitattributes
* whitespace=!indent,trail,space
*.[ch] whitespace=indent,trail,space
*.sh whitespace=indent,trail,space
$ git ls-files ":(attr:whitespace=indent)"
$ # no match!
So instead of matching exactly we'd want to just look for the value being
one part of the comma separated list as setup in .gitattributes.
However searching for more than one value will be complicated, as we'd then
need to escape commas. My vision was to use white spaces instead, but they
are now taken to separate different attributes.
So in the future I would imagine to have escaping like
git ls-files ":(attr:label=value\,value2 labelA=value3,exclude)
or yet another separator like
git ls-files ":(attr:label=value1;value2 labelA=value3,exclude)
Thanks,
Stefan
Stefan Beller (5):
string list: improve comment
Documentation: fix a typo
pathspec: move long magic parsing out of prefix_pathspec
pathspec: move prefix check out of the inner loop
pathspec: allow querying for attributes
Documentation/gitattributes.txt | 2 +-
Documentation/glossary-content.txt | 19 ++++
attr.c | 2 +-
attr.h | 2 +
dir.c | 46 ++++++++++
pathspec.c | 182 +++++++++++++++++++++++++++++--------
pathspec.h | 16 ++++
string-list.h | 2 +-
t/t6134-pathspec-with-labels.sh | 177 ++++++++++++++++++++++++++++++++++++
9 files changed, 407 insertions(+), 41 deletions(-)
create mode 100755 t/t6134-pathspec-with-labels.sh
--
2.8.2.121.ga97fb08
--
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