On Wed, Jan 23, 2013 at 5:51 AM, Junio C Hamano <gits...@pobox.com> wrote: > Junio C Hamano <gits...@pobox.com> writes: > >> We obviously do not want to set FNM_PATHNAME when we are not >> substituting fnmatch() with wildmatch(), but I wonder if it may make >> sense to unconditionally use WM_PATHNAME semantics when we build the >> system with USE_WILDMATCH and calling wildmatch() in this codepath. >> Users can always use "*/**/*" in place of "*" in their patterns >> where they want to ignore directory boundaries.
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? 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. > Another possibility, which _might_ make more practical sense, is to > update dowild() so that any pattern that has (^|/)**(/|$) in it > implicitly turns the WM_PATHNAME flag on. There is no reason for > the user to feed it a double-asterisk unless it is an attempt to > defeat some directory boundaries, They may also put "**" by mistake (or realize they just put "**" but too lazy to remove one asterisk). > so we already know that the user > expects WM_PATHNAME behaviour at that point. Otherwise, the user > would have simply said '*' instead, wouldn't he? 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) > I said "_might_" because it sounds a bit too magical to my taste. > I dunno. -- Duy -- 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
