Nguyễn Thái Ngọc Duy writes:
> .gitattributes pattern syntax is supposed to be the same as .gitignore
> (except a few things that do not make sense in attr context, but
> that's a different issue). .gitignore uses fnmatch() as the matching
> machinery and "\" is accepted as an escape code. In theory the pattern
> 'foo\ bar' should match path 'foo bar' in .gitignore. Granted, no one
> would write 'foo\ bar' in .gitignore when 'foo bar' should
> suffice.
>
> Regardless, 'foo\ bar attr' does not (but should) attach "attr" to
> path "foo bar" because pattern/attr parse code does not understand
> backslash escape. It parses the line as path 'foo\' and attributes
> 'bar' and 'attr'. This patch teaches attr code to recognize the
> backslash in patterns (not macro names) and pass 'foo\ bar' down to
> fnmatch().
>
> This changes the attr behavior. "foo\ attr", if exists in the field,
> would match nothing because path "foo\" is invalid in UNIX and is a
> directory in Windows, which we do not accept attaching attributes
> to. With this patch, that line becomes invalid and is rejected. So
> it's not really bad (i.e. no silent changes in behavior).
>
> Other subtle behavioral changes may happen. Still, I think we should
> do this as it seems like a correct thing to do.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> We discussed the "spaces in path names in attr" before and I remember
> using quotes or double quotes, even substituting spaces with
> dots, were raised. I don't remember if backslashes were mentioned.
My knee-jerk reaction, without thinking things through, is that this
makes sense and doing the same for .gitignore would, too (even
though the one-item-per-line nature of .gitignore makes "\ " and " "
practically equivalent).
Shouldn't we do the same for quoting fnmatch(3) metacharacters? To
match a path component 'a' followed by an asterisk followed by 'b',
you could then write 'a\*b'. Same for quoting the backslash itself.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
