On Wed, Dec 29, 2010 at 1:10 AM, Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy wrote: >> On Wed, Dec 22, 2010 at 2:31 AM, Ramsay Jones >> <ramsay@xxxxxxxxxxxxxxxxxxx> wrote: >>> The problem boils down to the call to strncmp_icase() suppressing the call to >>> fnmatch() when the pattern contains glob chars, but the (remaining) string is >>> equal to the name; thus returning an exact match (MATCHED_EXACTLY) rather than >>> calling fnmatch (and returning either no-match or MATCHED_FNMATCH). >> >> I think that's expected behavior. Wildcard pathspecs are fixed >> pathspecs will additional wildcard matching support and can match both >> ways. See 186d604 (glossary: define pathspec) > > Really? Hmm, that seems ... odd! (To be clear: you are saying that an exact > match, *even if the pattern contains glob chars*, takes precedence over the > glob match! - again *odd*) not exactly taking precedence. I would say it's "normal pathspecs with extra capability", so it can match more > Well, if you are happy with that ... Well, we have two options here: either that, or declare it a day (near) zero bug [1] with potentially massive impact. Personally I'd go with which ever way that is less work :) as long as it does not annoy me (much). [1] Exerpt from 56fc510 ([PATCH] git-ls-files: generalized pathspecs - 2005-08-21): "the "matching" criteria is a combination of "exact path component match" (the same as the git-diff-* family), and "fnmatch()"." Git makes digging history fun. -- Duy -- 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