Re: [PATCH 08/10] t2200, t7004: Avoid glob pattern that also matches files

[Johannes Sixt <j6t@kdbg.org>]

On Donnerstag, 19. März 2009, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> 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