summaryrefslogtreecommitdiff
path: root/doc/bugs/unexpected_double_wildcard_expansion.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'doc/bugs/unexpected_double_wildcard_expansion.mdwn')
-rw-r--r--doc/bugs/unexpected_double_wildcard_expansion.mdwn15
1 files changed, 15 insertions, 0 deletions
diff --git a/doc/bugs/unexpected_double_wildcard_expansion.mdwn b/doc/bugs/unexpected_double_wildcard_expansion.mdwn
new file mode 100644
index 000000000..f898a0c84
--- /dev/null
+++ b/doc/bugs/unexpected_double_wildcard_expansion.mdwn
@@ -0,0 +1,15 @@
+From the forum, it seems that git-ls-files very unexpectedly expands
+wildcards in filenames passed to it. (Not a documented or an expected
+behavior.)
+
+This causes problems when eg, the user does `git annex add *.jpeg` and that
+matches no files, but there are some jpegs in subdirectories. git-ls-files
+re-expands the wildcard and finds those.
+
+Seems that the best fix is to make Git.LsFiles paper over this git
+misfeature, by always escaping wildcards in paths passed
+to git-ls-files. AFAIK, no callers of Git.LsFiles expect to provide it
+wildcards, because I was completely surprised when I learned they were
+expanded.. --[[Joey]]
+
+> [[fixed|done]] --[[Joey]]