Johannes Sixt <j6t@xxxxxxxx> writes: > On Windows, there is an unfortunate interaction between the MSYS bash and > git's command line processing: > > - Since Windows's CMD does not do the wildcard expansion, but passes > arguments like path* through to the programs, the programs must do the > expansion themselves. This happens in the startup code before main() is > entered. > > - bash, however, passes the argument "path*" to git, assuming that git will > see the unquoted word unchanged as a single argument. > > But actually git expands the unquoted word before main() is entered. Doesn't this mean on Windows, the glob pathspec git supports is not useful at all? I am wondering if we want to treat any feature that involves globs as unusable like any feature that involves pathnames with a TAB in it. > 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. -- 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
