]> git.ipfire.org Git - thirdparty/git.git/commit
doc: document backslash in gitignore patterns
authorJeff King <peff@peff.net>
Wed, 29 Oct 2025 15:32:37 +0000 (11:32 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 29 Oct 2025 16:17:21 +0000 (09:17 -0700)
commit8a6d158a1d69996542ec0d28b63e83eaf46c5945
tree56b8b16716b4d371f59a65c713c503f299511780
parentbb5c624209fcaebd60b9572b2cc8c61086e39b57
doc: document backslash in gitignore patterns

Because gitignore patterns are passed to fnmatch, the handling of
backslashes is the same as it is there: it can be used to escape
metacharacters. We do reference fnmatch(3) for more details, but it may
be friendlier to point out this implication explicitly (especially for
people who want to know about backslash handling and search the
documentation for that word). There are also two cases that I've seen
some other backslash-escaping systems handle differently, so let's
describe those:

  1. A backslash before any character treats that character literally,
     even if it's not otherwise a meta-character. As opposed to
     including the backslash itself (like "foo\bar" in shell expands to
     "foo\bar") or forbidding it ("foo\zar" is required to produce a
     diagnostic in C).

  2. A backslash at the end of the string is an invalid pattern (and not
     a literal backslash).

This second one in particular was a point of confusion between our
implementation and the one in JGit. Our wildmatch behavior matches what
POSIX specifies for fnmatch, so the code and documentation are in line.
But let's add a test to cover this case. Note that the behavior here
differs between wildmatch itself (which is what gitignore will use) and
pathspec matching (which will only turn to wildmatch if a literal match
fails). So we match "foo\" to "foo\" in pathspecs, but not via
gitignore.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/gitignore.adoc
t/t3070-wildmatch.sh