If */test*
matches some file(s), your shell will expand this expression. Try:
echo */test*
at the shell prompt. Compare, for instance:
$ cd /tmp
$ mkdir empty
$ cd empty
$ echo */test*
*/test*
/tmp/empty
is empty so */test*
matches nothing. But then:
$ mkdir dir; touch dir/test.file
$ echo */test*
dir/test.file
So, if you have nothing matching */test*
and you run:
$ somegitcommand */test*
the git command will see */test*
as its argument; but if you have something that matches, the git command will see dir/test.file
as its argument. The *
s have vanished.
The fix is really super-simple: quote the */test*
part:
$ git log --oneline -- '*/test*'
Now git log
will see */test*
, rather than dir/test.file
, and git will be able to do recursive matching.
It's worth mentioning that not all shells behave the same way. In csh and tcsh, if there is no match for a shell glob like */test.*
, you get:
> rm -r dir
> echo */test*
echo: No match.
In bash, you can choose the behavior:
bash$ echo */test*
*/test*
bash$ shopt -s failglob
bash$ echo */test*
bash: no match: */test*
(in fact you can do the same in csh and tcsh; it's just inverted: set nonomatch
and the */test*
is passed through to echo
).
Also, this illustrates the difference between the shell's wildcard globbing (which does not recurse into subdirectories) and git's (which does). See Jubobs' answer and try (in the shell) echo */*/test*
vs echo */test*
(all without quotes). Some shells have recursive globbing that can be enabled in various ways, such as using **
to indicate recursion is desired: echo **/test*
.
One last note: git's wildcard matching has changed somewhat from one version to another, especially in .gitignore
files. Specifically, **
meaning "zero or more directories" (specifically in .gitignore
files) was added to git in version 1.8.2.