On Thu, Oct 11, 2018 at 2:41 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Thu, Oct 11 2018, dana wrote: > > > Hello, > > > > I'm a contributor to ripgrep, which is a grep-like tool that supports using > > gitignore files to control which files are searched in a repo (or any other > > directory tree). ripgrep's support for the patterns in these files is based on > > git's official documentation, as seen here: > > > > https://git-scm.com/docs/gitignore > > > > One of the most common reports on the ripgrep bug tracker is that it does not > > allow patterns like the following real-world examples, where a ** is used along > > with other text within the same path component: > > > > **/**$$*.java > > **.orig > > **local.properties > > !**.sha1 > > > > The reason it doesn't allow them is that the gitignore documentation explicitly > > states that they're invalid: > > > > A leading "**" followed by a slash means match in all directories... > > > > A trailing "/**" matches everything inside... > > > > A slash followed by two consecutive asterisks then a slash matches zero or > > more directories... > > > > Other consecutive asterisks are considered invalid. Perhaps "undefined" is a better word than "invalid". > > git itself happily accepts these patterns, however, apparently treating the ** > > like a single * without fnmatch(3)'s FNM_PATHNAME flag set (in other words, it > > matches / as a regular character, thus crossing directory boundaries). > > > > ripgrep's developer is loathe to reverse-engineer this undocumented behaviour, > > and so the reports keep coming, both for ripgrep itself and for down-stream > > consumers of it and its ignore crate (including most notably Microsoft's VS Code > > editor). > > > > My request: Assuming that git's actual handling of these patterns is intended, > > would it be possible to make it 'official' and explicitly add it to the > > documentation? You mean "**" in the fourth case is interpreted as "*"? Yes I guess we could rephrase it as "Other consecutive asterisks are considered normal wildcard asterisks" > Yeah those docs seem wrong. In general the docs for the matching > function are quite bad. I have on my TODO list to factor this out into > some gitwildmatch manpage, but right now the bit in gitignore is all we > have. > > Our matching function comes from rsync originally, whose manpage says: > > use ’**’ to match anything, including slashes. > > I believe this is accurate as far as the implementation goes. No. "**" semantics is not the same as from rsync. The three cases "**/", "/**/" and "/**" were requested by Junio if I remember correctly. You can search the mail archive for more information. -- Duy
