Junio C Hamano <gits...@pobox.com> writes:

> Duy Nguyen <pclo...@gmail.com> writes:
>> On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen <pclo...@gmail.com> wrote:
>>> :(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.
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

Reply via email to