Hi, I think there's a small mismatch with how git handles escaped trailing spaces in .gitignore.
Repro
Put this in your .gitignore:
$ printf 'foo\\ \n' > .gitignore
$ od -c .gitignore
0000000 f o o \ \n
(that's foo, then a backslash, then three spaces. I'm using printf/od here because trailing spaces are invisible in a code block)
Now check a file with a trailing space:
$ git check-ignore -v 'foo '
.gitignore:1:foo\ foo
Git accepts this and ignores foo correctly.
But ripgrep throws an error:
$ rg hi
rg: ./.gitignore: line 1: error parsing glob 'foo\': dangling '\'
What's going on
From what I can tell, git trims normal trailing spaces but keeps the escaped one. So this pattern ends up matching foo .
In ripgrep, the trailing spaces seem to get trimmed a bit too aggressively. In this case, it removes the escaped space as well, leaving foo\, which then becomes a dangling backslash and causes a parse error.
Expected
It would be nice if this behaved like git:
- no parse error
- pattern matches
foo
Notes
This feels similar to #2236, where a technically valid but uncommon pattern caused a dangling \ error and was fixed.
Totally understand if this is considered too edge-casey, but since git accepts it, thought it might be worth flagging.
Hi, I think there's a small mismatch with how git handles escaped trailing spaces in .gitignore.
Repro
Put this in your
.gitignore:(that's
foo, then a backslash, then three spaces. I'm using printf/od here because trailing spaces are invisible in a code block)Now check a file with a trailing space:
Git accepts this and ignores
foocorrectly.But ripgrep throws an error:
What's going on
From what I can tell, git trims normal trailing spaces but keeps the escaped one. So this pattern ends up matching
foo.In ripgrep, the trailing spaces seem to get trimmed a bit too aggressively. In this case, it removes the escaped space as well, leaving
foo\, which then becomes a dangling backslash and causes a parse error.Expected
It would be nice if this behaved like git:
fooNotes
This feels similar to #2236, where a technically valid but uncommon pattern caused a dangling
\error and was fixed.Totally understand if this is considered too edge-casey, but since git accepts it, thought it might be worth flagging.