git ls-files wildcard behavior considered harmful

I was very surprised to learn the other day that git ls-files 'foo*' will expand wildcards (including character classes), in the absence of expansion by the shell. (git version 2.1.4)

joey@darkstar:~/tmp/aaa>git ls-files 'foo*bar' foo*bar foobazbar joey@darkstar:~/tmp/aaa>git ls-files '[abc]' [abc] a b

As far as I can see this behavior is not documented on the man page, except for a tiny mention in the --with-tree documentation, where it says "<file> (i.e. path pattern)".

Since I wanted to avoid this wildcard expension, I tried slash-escaping the wildcard characters. This works:

joey@darkstar:~/tmp/aaa>git ls-files 'foo\*bar' foo*bar joey@darkstar:~/tmp/aaa>git ls-files '\[abc\]' [abc]

But, there is a weird behavior here with subdirectories. While normally ls-files would recurse, slash-escaped wildcard characters in the directory name prevent recursion.

joey@darkstar:~/tmp/aaa>git ls-files 'foo[d]' foo[d]/subfile food joey@darkstar:~/tmp/aaa>git ls-files 'foo\[d\]' joey@darkstar:~/tmp/aaa>

The above example shows a case where it's impossible to get ls-files to only list files in a directory and not other files that match the wildcard. This seems like it must be a bug, and it means it's impossible to reliably work around the wildcard expansion behavior.

I suspect that this wildcard expansion behavior is useful somewhere. But from the perspective of using ls-files as plumbing, where you want to get out some subset of what was put in, it's not nice.