Johannes Sixt <j6t@xxxxxxxx> writes: > No, it is still useful. There is a difference if I say > > git add "*a*" > > from bash or from Windows's CMD. The latter passes the argument to git with > the dquotes; the startup code removes them and does not expand the wildcard. > But if bash invokes the command, bash removes the quotes, so that the startup > code only sees *a* and does the expansion. I can only say "yuck" :-<. >> > In t2200, not all names that the test case is interested in exist as >> > files at the time when 'git ls-files' is invoked. git expands "path?" to >> > only the subset of files the exist, and only that subset was listed, so >> > that the test failed. We now list all interesting paths explicitly. >> >> But that conversion misses the whole point of that particular test, >> doesn't it? It wants to see path2 that was unmerged and existed only in >> the index but not in the work tree has disappeared, while the similarly >> unmerged path1 resolved after "add -u". IOW, you are not testing that >> "add -u" notices a removal of path2 from the work tree anymore. > > I see. Then I'll just add path2 to the list, OK? It still passes the test. Yeah, as we are not passing --error-unmatch to the command, it should be the right thing to do. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
