{"thread":{"id":"46912","subject":"wildmatch + fnmatch compatibility","startedAt":"2017-10-05T14:07:23Z","lastAt":"2017-10-05T14:07:23Z","messageCount":1,"participants":["Zachary Newman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"329771","messageId":"CALba54S3+dhbptijxTyqsDUmfstm48TVUKaejAsyGNv2YkHoYg@mail.gmail.com","threadId":"46912","inReplyTo":null,"subject":"wildmatch + fnmatch compatibility","fromName":"Zachary Newman","fromEmail":"znewman01@gmail.com","sentAt":"2017-10-05T14:07:16Z","receivedAt":"2017-10-05T14:07:23Z","isPatch":false,"sender":{"key":"znewman01@gmail.com","avatar":null},"body":"Hi all,\n\nI noticed a possible inconsistency in the documentation for\n.gitignore; the pertinent bit is:\n\n    If the pattern does not contain a slash /, Git treats it as a\nshell glob pattern\n    and checks for a match against the pathname relative to the location of the\n    .gitignore file\n\n    ...\n\n    Otherwise, Git treats the pattern as a shell glob suitable for\n    consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in\n    the pattern will not match a / in the pathname.\n\nHowever, notice:\n\n    $ cd $(mktemp -d)\n    $ git init\n    $ touch '['\n    $ echo -e '.gitignore\\n[' > .gitignore\n    $ git add --dry-run .\n    add '['\n    $ python -c \"import fnmatch; print fnmatch.fnmatchcase('[', '[')\"\n    True\n\nSpecifically, git *does not* match the string '[' while fnmatch\n*does*. \"Git treats it\nas a shell glob pattern\" could mean that the globbing is different\nfrom fnmatch,\nbut 'test/[' exhibits the same behavior.\n\nI believe this is the result of an inconsistency in between wildmatch\nand fnmatch[1]:\n\n    printf(\"%d\\n\", fnmatch(\"[\", \"[\", FNM_PATHNAME);  // prints 0,\nindicating a match\n    printf(\"%d\\n\", wildmatch(\"[\", \"[\", WM_PATHNAME);  // prints -1,\nindicating error\n\nWhile the way wildmatch handles this makes sense (it *is* a malformed pattern),\nit doesn't square with the documentation for .gitignore [2].\n\nThere are a few ways that I can think of to resolve this:\n\n* update the documentation to reflect that the syntax is similar but\nnot identical to\n  fnmatch.\n* update the behavior of wildmatch to match fnmatch.\n* leave the behavior of wildmatch, but fall back to fnmatch if there's an error.\n* decide that anybody who comes to depend on this behavior is already in\n  dangerous territory, and it's not worth addressing.\n* decide that I'm wrong.\n\n(As an aside: I trolled through the mailing list a bit but couldn't\nfind a rationale\nfor using wildmatch instead of fnmatch---it looks to be related to a desire to\nsupport '**' patterns in .gitignore, maybe?)\n\nCheers,\nZack\n\n\n[1] Specifically, I've tested on both a macOS (BSD) implementation and\nUbuntu (GNU) implementation of fnmatch. Additionally, if I'm reading the\nspecification right, it claims \"If an open bracket introduces a\nbracket expression\nas in XBD RE Bracket Expression...it shall introduce a pattern bracket\nexpression....Otherwise, '[' shall match the character itself.\"\n(<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_02>)\n\n[2] There's one caveat: none of the older versions I tested with\nignore '[' either.\nIn particular, 1.8.2.3 just prints \"ha!\" (which seems like it\nindicates an error) and\n1.8.3.1 includes '['; both of these are before the 1.8.4 release, when\nthe cut over\nto using wildmatch occurred.\n"}]}