Re: [RFC] The design of new pathspec features

Junio C Hamano [off-list ref] writes:

Duy Nguyen [off-list ref] writes:

quoted

On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen [off-list ref] wrote:

quoted

:(glob) magic
=============

This magic is for people who want globbing. However, it does _not_ use
the same matching mechanism the non-magic pathspec does today. It uses
wildmatch(WM_PATHNAME), which basically means '*' does not match
slashes and "**" does.

Global option --glob-pathspecs is added to add :(glob) to all
pathspec. :(literal) magic overrides this global option.

I forgot one thing. The current pathspec behavior, the pattern "[a-z]"
would match a file named "[a-z]" (iow, wildcards are also considered
literal characters).

That sounds like a blatant bug to me (unless you are talking about
"literal" case).  We should fix it before we include it in any
released version, I think.

Ah, no, I misread what you meant.

Yes, historically when matching a path with a pattern "a/b[c-d]/e",
we tried to first literally match the path with it (this allows the
path "a/b[c-d]/e" to match with the pattern), and if it did not
match, used fnmatch(3) to allow "a/bc/e" to also match.  This was an
ugly hack to cope with the possiblity that such a funny path is
actually used in projects.

With :(literal) magic and its friends you are working into the
system, the hack should disappear at the same time when you stop
running fnmatch(3) without FNM_PATHNAME.  That should happen no
later than Git 2.0.

But until then, we should keep matching both paths "a/bc/e" and
"a/b[c-d]/e" with pattern "a/b[c-d]/e", for backward compatibility.

Sorry about the earlier confusion.