ripgrep: ./.gitignore: line 2: invalid use of **; must be one path component

**/something is valid .gitignore syntax, but rg prints an error

A leading “**” followed by a slash means match in all directories. For example, “**/foo” matches file or directory “foo” anywhere, the same as pattern “foo”. “**/foo/bar” matches file or directory “bar” anywhere that is directly under directory “foo”. (https://git-scm.com/docs/gitignore)

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 24 (13 by maintainers)

Commits related to this issue

lnd: use single asterisk for gitignore wildcards This stops ripgrep from complaining about invalid use of **; must be one path component See https://github.com/BurntSushi/ripgrep/issues/373 — committed to asoltys/lnd by asoltys 6 years ago
lnd: use single asterisk for gitignore wildcards This stops ripgrep from complaining about invalid use of **; must be one path component See https://github.com/BurntSushi/ripgrep/issues/373 — committed to lightningnetwork/lnd by asoltys 6 years ago
lnd: use single asterisk for gitignore wildcards This stops ripgrep from complaining about invalid use of **; must be one path component See https://github.com/BurntSushi/ripgrep/issues/373 — committed to jonasnick/lnd by asoltys 6 years ago

Most upvoted comments

I’m going to close this because the current behavior is the conservative choice, and being conservative allows us to be flexible in the future. In particular, I think there is either a specification bug or an implementation bug in git, and I don’t know which one it is.

BurntSushi on May 8, 2017

This is now fixed for good on master. ripgrep recognizes previously invalid ** patterns as two consecutive * patterns, in line with git’s updated spec.

BurntSushi on Jan 24, 2019

Current master has a --no-ignore-messages that will suppress just these types of error messages. It will be in the next release.

BurntSushi on Apr 28, 2018

Had the same issue, I always thought git used fnmatch for this. I looked through git and see that actually moved to use wildmatch (https://github.com/davvid/wildmatch) in recent versions. Without looking too much into it I think this may be the reason for it.

The wildmatch extension allows ** to match / when WM_PATHNAME is present. This gives the practical benefit of being able to match all subdirectories of a path by using ** and reserves the use of the single-asterisk * character for matching within path components.

derimagia on Mar 31, 2017

I have sent an email to the Git mailing list requesting that the **.extension format be added to the documentation of Git ignore.

It already has been. See the commit referenced in #1098

okdana on Nov 25, 2018

@BurntSushi imho it might be worth choosing consistency with implementation over spec in this case and making a prominent note of it

millerjs on Apr 8, 2017

It looks like *literal will be matched prior to a call to wildmatch. If it’s **literal, it will be passed to wildmatch, where the first and second wildcards will be consumed, the WM_PATHNAME flag will not have been set, the rest of theliteral text consumed, and a successful match will be returned.

Side note, wildmatch was integrated in v1.8.2-rc0 and a prior tag (v1.8.1.6) reproduces the behavior of git to match **.txt to hello.txt so it seems it wasn’t a bug introduced when wildmatch was integrated.

Looks like the spec and implementation are just inconsistent…?

millerjs on Apr 3, 2017