Re: [PATCH] doc: document backslash in gitignore patterns

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Oct 30, 2025, 13:40 UTC
Message-ID: <CALnO6CButUc89H0a+FrrdY4pWh10=U8yeWfd7Oesb=1wpHMmSg@mail.gmail.com>
In-Reply-To: <20251029155559.GA1134232@coredump.intra.peff.net>

On Wed, Oct 29, 2025 at 12:32 PM Jeff King <peff@peff.net> wrote:

Show 19 quoted lines

>
> On Wed, Oct 29, 2025 at 11:32:37AM -0400, Jeff King wrote:
>
> > Subject: [PATCH] doc: document backslash in gitignore patterns
>
> Oh, I forgot to mention: obviously gitattributes inherits the same
> behavior here. I looked at whether it would want a similar patch, but it
> does not define the pattern format at all, and just punts to "see
> gitignore(5) for details". I think that's OK. Unlike where we refer to
> fnmatch(3) here, you cannot even begin to wonder how backslashes are
> handled by gitattributes without reading gitignore(5). ;)
>
> There's also the "pathspec" entry in gitglossary(7), which does mention
> fnmatch(3). Though it is even more confusing because of the literal
> matching that pathspecs do. I don't know if we'd want anything there
> (and I kind of doubt people get as exotic about patterns there as they
> would in gitignore).
>
> -Peff

I certainly wondered about the pathspec case, since the commit message called out the difference in behavior. For example, at least in this one corner, we can't reliably use Git commands with pathspecs to build up example gitignore patterns to throw in .gitignore?

BTW, is the literal matching intended to be conveyed by

           •   any path matches itself

? If so, I'm not quite sure how to interpret a pathspec like a/b given a repo with a/b and dir/a/b—do both match or only the former? I expect in combination with the 2 subsequent bullets that only the former matches. Conversely, with a pathspec "b" in that case, I think I could read the docs as suggesting both match, when IIRC none do. Hm!

But this is a bit of a tangent, and the pathspec entry is already, uh, complicated [1]. Without a good place to leave extra notes for cases like this, I'm not sure what to do. Certainly unifying the behavior would be incompatible (if obscure).

[1]: https://lore.kernel.org/git/20250802094657.GG3711639@coredump.intra.peff.net/

-- 
D. Ben Knoble