Am 23.08.2011 20:09, schrieb Junio C Hamano:
Ramsay Jones<ramsay@xxxxxxxxxxxxxxxxxxx> writes:Commit 704c335 (On Cygwin support both UNIX and DOS style path-names, 05-08-2011) in pu needs an update to fix the commit message.Thanks for a reminder, Ramsay. Here is the exchange where fixing the commit log was mentioned. From: Pascal Obry<pascal@xxxxxxxx> Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names To: Ramsay Jones<ramsay@xxxxxxxxxxxxxxxxxxx> Cc: git@xxxxxxxxxxxxxxx Date: Sat, 13 Aug 2011 19:34:37 +0200 Message-ID:<4E46B5AD.5050806@xxxxxxxx> Le 11/08/2011 22:35, Ramsay Jones a écrit : > ... could you please correct your commit message. Thanks! Done, thanks for your review.Also, I didn't see any response to Johannes Sixt's query concerning backslash in pathspec. (I personally don't want to go down that route, but ...)Here is what J6t said in the message: From: Johannes Sixt<j6t@xxxxxxxx> Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names Date: Tue, 09 Aug 2011 21:47:15 +0200 Message-ID:<4E418EC3.4070904@xxxxxxxx> > Do you also want to support this: > $ git add src\file.c > i.e., backslash in pathspec? Then you need more than this: > > +#define has_dos_drive_prefix(path) (isalpha(*(path))&& (path)[1] == ':') > > +#define is_dir_sep(c) ((c) == '/' || (c) == '\\') > > In particular, you have to enable backslash processing in > setup.c:prefix_filename(), but then you lose the ability to escape > special characters with the backslash. When "git add src\file.c" is given from the command line, what does our main() see in argv[2]? Do cmd.exe and bash give us the same thing? What if the command line is "git add 'src\*.c'"?
Our main() sees the string as given on the command line, i.e., with the backslash.
I vaguely recall that on Windows you only get a single parameter string
from the program loader, and arguments are split in the invoked process,
but that is so common that as far as our main() is concerned we can expect
the example command line to give us argc=3 and argv={ "git", "add", "???",
NULL }. What I do not recall is if there is some other magic such as
expanding shell globs and swapping the direction of slashes in strings
involved when this argument processing is done.
There is a linker option whether shell globs should be expanded or not before they are passed to main(). If the option is enabled, the expansion is different from the way mandated by POSIX.
There was a proposal recently (on the msysgit list?) that this option should be disabled, and any expansion of pathspec (globs) should be done entirely by git's own expansion rules, which includes automatic recursive matching. As a result, git would behave differently on Windows and Unix, but since it already does when the linker option is enabled, we argue that git's rules are superior (and Windows's linker option is inferior), we better should go the proposed new route.
You probably _could_ do '\\' -> '/' inside prefix_filename() and get_pathspec(), but as J6t mentioned, we _do_ handle backslash as a quoting character, and this is _not_ going to change.
... not going to change on platforms where this already works. It does not work on Windows.
So even if we were to go that route, the user would need to make git see "src\\file.c" or "src\\*.c" in order to make it turn into "src/file.c" and "src/*.c" pathspec. If it means that the user needs to type: $ git add src\\\\file.c I would have to say that it would be simpler for them to say $ git add src/file.c even on Cygwin. After all, isn't Cygwin for people who are forced to be on Windows and miss POSIXy environments? By the way, Johannes, how does Git for Windows handle pathspecs?
On Windows, prefix_filename() and prefix_path() (the latter via normalize_path_copy()) transform any backslashes to forward-slashes. Therefore, if you have src\*.c on the command line, it is processed as src/*.c. That is, if \ was meant to escape the *, then this would not work. It does not help to duplicate backslashes, because all of them are transformed to forward-slashes before git's glob expansion kicks in.
-- 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