On Donnerstag, 16. Dezember 2010, Ramsay Jones wrote:
> Johannes Sixt wrote:
> > On Dienstag, 14. Dezember 2010, Ramsay Jones wrote:
> >> Note t3700-*.sh has a test protected by BSLASHSPEC which
> >> previously passed on cygwin and will now be (unnecessarily)
> >> skipped. This test needs to be skipped on MinGW, given how
> >> it is written; if you remove the single quotes around the
> >> filename, however, it will pass even on MinGW.
> >
> > That is suspicious. It would mean that git add does not do file globbing
> > anymore. Should it or should it not do file globbing?
>
> Hmm, something like "git add 'a.[ch]'" works just fine. The problems
> occur when you back-quote the metachars like "git add 'a.\[ch\]'".
>
> The test is skipped on MinGW, because of BSLASHSPEC. The test is now
> skipped on cygwin, after this patch, even though it passes on cygwin.
> BSLASHSPEC is, apparently, used for both a '\' in a filename and for
> a "\-quoting". (Perhaps it should be split into two prerequisites)
>
> The difference in behaviour between cygwin and MinGW (& msvc) is easy
> to trace, thus:
>
> cmd_add()
> =>validate_pathspec() builtin/add.c:435
> =>get_pathspec() builtin/add.c:216
> =>prefix_path() setup.c:147
> =>normalize_path_copy() setup.c:18
> =>is_dir_sep()
>
> on cygwin is_dir_sep() is defined thus:
>
> git-compat-util.h:208:#define is_dir_sep(c) ((c) == '/')
>
> where on MinGW it is defined thus:
>
> compat/mingw.h:291:#define is_dir_sep(c) ((c) == '/' || (c) == '\\')
>
> So, on entry to git-add the pathspec (in argv[1]) is
> fo\[ou\]bar
> On return from validate_pathspec(), on cygwin it is *still*
> fo\[ou\]bar
> but on MinGW (and msvc), it is now
> fo/[ou/]bar
>
> and everything follows from there. (So for example, on cygwin, match_one()
> matches fo\[ou\]bar with fo[ou]bar, but not with foobar.)
Yes, that's clear, and this is the reason that we must skip this test on
MinGW.
But you said that when the single quotes are removed, the test passes (and you
are right). Then git-add sees this pathspec/pattern:
fo[ou]bar
and it matches 'foobar' when it interprets that as a pattern, but 'fo[ou]bar'
when it interprets that as straight file name. Even on Linux, the latter
happens, and *that* is suspicious. What am I missing?
-- 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