wildmatch + fnmatch compatibility

Hi all,

I noticed a possible inconsistency in the documentation for .gitignore; the pertinent bit is:

    If the pattern does not contain a slash /, Git treats it as a
shell glob pattern
    and checks for a match against the pathname relative to the location of the
    .gitignore file

    ...

    Otherwise, Git treats the pattern as a shell glob suitable for
    consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in
    the pattern will not match a / in the pathname.

However, notice:

    $ cd $(mktemp -d)
    $ git init
    $ touch '['
    $ echo -e '.gitignore\n[' > .gitignore
    $ git add --dry-run .
    add '['
    $ python -c "import fnmatch; print fnmatch.fnmatchcase('[', '[')"
    True

Specifically, git *does not* match the string '[' while fnmatch *does*. "Git treats it as a shell glob pattern" could mean that the globbing is different from fnmatch, but 'test/[' exhibits the same behavior.

I believe this is the result of an inconsistency in between wildmatch and fnmatch[1]:

    printf("%d\n", fnmatch("[", "[", FNM_PATHNAME);  // prints 0,
indicating a match
    printf("%d\n", wildmatch("[", "[", WM_PATHNAME);  // prints -1,
indicating error

While the way wildmatch handles this makes sense (it *is* a malformed pattern), it doesn't square with the documentation for .gitignore [2].

There are a few ways that I can think of to resolve this:

* update the documentation to reflect that the syntax is similar but
not identical to
  fnmatch.
* update the behavior of wildmatch to match fnmatch.
* leave the behavior of wildmatch, but fall back to fnmatch if there's an error.
* decide that anybody who comes to depend on this behavior is already in
  dangerous territory, and it's not worth addressing.
* decide that I'm wrong.

(As an aside: I trolled through the mailing list a bit but couldn't find a rationale for using wildmatch instead of fnmatch---it looks to be related to a desire to support '**' patterns in .gitignore, maybe?)

Cheers, Zack

[1] Specifically, I've tested on both a macOS (BSD) implementation and Ubuntu (GNU) implementation of fnmatch. Additionally, if I'm reading the specification right, it claims "If an open bracket introduces a bracket expression as in XBD RE Bracket Expression...it shall introduce a pattern bracket expression....Otherwise, '[' shall match the character itself." (<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_02>)

[2] There's one caveat: none of the older versions I tested with ignore '[' either. In particular, 1.8.2.3 just prints "ha!" (which seems like it indicates an error) and 1.8.3.1 includes '['; both of these are before the 1.8.4 release, when the cut over to using wildmatch occurred.