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.)
ATB,
Ramsay Jones
--
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