Junio C Hamano <gitster@xxxxxxxxx> writes: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen <pclouds@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html