git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* wildmatch + fnmatch compatibility
@ 2017-10-05 14:07 Zachary Newman
  0 siblings, 0 replies; only message in thread
From: Zachary Newman @ 2017-10-05 14:07 UTC (permalink / raw)
  To: git

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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2017-10-05 14:07 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-05 14:07 wildmatch + fnmatch compatibility Zachary Newman

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).