On Thu, Dec 20, 2012 at 12:24 AM, Junio C Hamano <gits...@pobox.com> wrote: > When that happens, we should want to retain the same "do not bother > to descend into subdirectories that will never match" optimization > for a pattern like "Doc*tion/**/*.txt". Because of FNM_PATHNAME, we > can tell if a subdirectory is worth descending into by looking at > the not-so-simple prefix "Doc*tion/"; "Documentation" will match, > "Doc" will not (because '*' won't match '/'). > > Which tells me that integrating this _well_ into the rest of the > system is not just a matter of replacing fnmatch() with wildmatch().
Yeah, we open a door for more opportunities and a lot more headache. > I also expect that wildmatch() would be much slower than fnmatch() > especially when doing its "**" magic, but I personally do not think > it will be a showstopper. A potential showstopper is the lack of multibyte support. I don't know if people want that though. > If the user asks for a more powerful but > expensive operation, we are saving time for the user by doing a more > powerful thing (reducing the need to postprocess the results) and > can afford to spend extra cycles. In some case we may be able to spend fewer cycles by preprocessing patterns first. > As long as simpler patterns fnmatch() groks (namely, '?', '*', and > '[class]' wildcards only) are not slowed down by replacing it with > wildmatch(), that is, of course. I'm concerned about performance vs fnmatch too. I'll probably write a small program to exercise both and measure it with glibc. -- 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
