On Thu, May 30, 2013 at 9:25 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> This makes git use wildmatch by default for all fnmatch() calls. Users >> who want to use system fnmatch (or compat fnmatch) need to set >> NO_WILDMATCH flag. >> >> wildmatch is a drop-in fnmatch replacement with more features. Using >> wildmatch gives us a consistent behavior across platforms. > > While I agree this is a good move in the longer term in that we get > the often-asked-for "foo/**/*.c" match and also we have one less > platform differences to worry about, I somehow have a recollection > that we discussed that there are incompatibilities in dark corners > we would want to warn users about and lay a transition plan across > some major version bump. I've skimmed through all wildmatch related mails in my gmail archive. There are differences between fnmatch versions, e.g. [1], but I don't think anyone would run into those cases on purpose. There were performance concerns [2] and they should have been addressed with nd/retire-fnmatch series. Originally I was worried that this new code might not be mature enough, but I've been running wildmatch-only git for quite some time, can't really complain. Not really a transition plan, but maybe we could provide a runtime switch to return to system fnmatch when wildmatch becomes default, for a few cycles. This way if wildmatch turns out broken, people can switch back while we work on a fix. > Hmph, could you (no need to hurry, though) check the previous > discussion and point at what we decided if we did reach any > conclusion to refresh our collective memory? We all seemed to agree that the replacement would be a way to go. But not hard decision was reached. [1] http://thread.gmane.org/gmane.comp.version-control.git/207385/focus=207540 [2] http://thread.gmane.org/gmane.comp.version-control.git/211823/focus=211836 -- 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