Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)

[Johannes Sixt <j6t@kdbg.org>]

Am 23.08.2011 20:09, schrieb Junio C Hamano:
> Ramsay Jones<ramsay@ramsay1.demon.co.uk>  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@obry.net>
>      Subject: Re: [PATCH 2/2] On Cygwin support both UNIX and DOS style path-names
>      To: Ramsay Jones<ramsay@ramsay1.demon.co.uk>
>      Cc: git@vger.kernel.org
>      Date: Sat, 13 Aug 2011 19:34:37 +0200
>      Message-ID:<4E46B5AD.5050806@obry.net>
>
>      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@kdbg.org>
>    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@kdbg.org>
>
>    >  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