On Donnerstag, 19. März 2009, Junio C Hamano wrote: > 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? 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. > > 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. -- Hannes -- 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
