From: Joey Hess <id@joeyh.name>
Date: Mon, 30 Mar 2015 23:04:59 GMT
Subject: git ls-files wildcard behavior considered harmful
Message-ID: <20150330230459.GA13927@kitenet.net>

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.

-- 
see shy jo