On Thu, May 30, 2013 at 9:25 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclo...@gmail.com> 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. , but I don't
think anyone would run into those cases on purpose. There were
performance concerns  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.
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