Duy Nguyen <pclo...@gmail.com> writes: > If we do that, we need to do the same in tree_entry_interesting(). In > other words, pathspec learns the new glob syntax. It's fine for an > experimental flag like USE_WILDMATCH. But after fnmatch is replaced by > wildmatch unconditionally (thus USE_WILDMATCH becomes obsolete), then > what? Should people who expects new syntax with USE_WILDMATCH continue > to have new syntax? How does a user know which syntax may be used in > his friend's "git" binary?
Good point. > On a related subject, I've been meaning to write a mail about the > other use of patterns in git (e.g. in git-branch, git-tag, > git-apply...) but never got around to. Some use without FNM_PATHNAME, > some do and the document does not go into details about the > differences. We might want to unify the syntax there too. It'll > probably break backward compatibility so we can do the same when we > switch pathspec syntax. Right now, I think for-each-ref is the only one with FNM_PATHNAME. With the experimental USE_WILDMATCH, "for-each-ref refs/**/master" will give us what is naturally expected. With a working wildmatch, I think it probably makes sense to globally enable FNM_PATHNAME; it would probably be nice if we could do so at Git 2.0 version bump boundary, but I suspect we are not ready yet (as you pointed out, there are still codepaths that need to be adjusted). > The only problem I see is, without the version string, there's no way > to know if "**" is supported. Old git versions will happily take "**" > and interpret as "*". When you advise someone to use "**" you might > need to add "check if you have this version of git". This problem does > not exist with pathspec magic like :(glob) OK, so what do we want to do when we do the real "USE_WILDMATCH" that is not the current experimental curiosity? Use ":(wild)" or something? -- 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