Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Whenever you call a non-MSYS program from an MSYS program (and remember, > an MSYS program is a program that uses the MSYS2 runtime that acts as a > POSIX emulation layer), "magic" things are done. In our context, > `bash.exe` is an MSYS program, and the non-MSYS program that is called is > `git.exe`. > > So what are those "magic" things? The command-line arguments and the > environment variables are auto-converted: everything that looks like a > Unix-style path (or path list, like the `PATH` environment variable) is > converted to a Windows-style path or path list (on Windows, the colon > cannot be the separator in `PATH`, therefore the semicolon is used). > > And this is where it gets _really_ tricky to explain what is going on: > what _does_ look like a Unix-style path? The exact rules are convoluted > and hard to explain, but they work _most of the time_. For example, > `/usr/bin:/hello` is converted to `C:\Program Files\Git\usr\bin;C:\Program > Files\Git\hello` or something like that. But `kernel.org:/home/gitster` is > not, because it looks more like an SSH path. Similarly, `C:/Program Files` > is interpreted as a Windows-style path, even if it could technically be a > Unix-style path list. > > Now, if you call `git.exe -C /blabla <command>`, it works, because > `git.exe` is a non-MSYS program, therefore that `/blabla` is converted to > a Windows-style path before executing `git.exe`. However, when you write a > file via `echo /blabla >file`, that `echo` is either the Bash built-in, or > it is an MSYS program, and no argument conversion takes place. If you > _then_ ask `git.exe` to read and interpret the file as a path, it won't > know what to do with that Unix-style path. > > You can substitute `$PWD` for `/blabla` in all of this, and it will hold > true just the same. > > So what makes `pwd` special? > > Well, `pwd.exe` itself is an MSYS program, so it would still report a path > that `git.exe` cannot understand. But in Git's test suite, we specifically > override `pwd` to be a shell function that calls `pwd.exe -W`, which does > output Windows-style paths. > > The thing that makes that `GIT_*=$PWD git ...` call work is that the > environment is automagically converted because `git` is a non-MSYS > program. The thing that makes `echo $PWD >.git/objects/info/alternates` > not work is that `echo` _is_ an MSYS program (or Bash built-in, which is > the same thing here, for all practical purposes), so it writes the path > verbatim into that file, but then we expect `git.exe` to read this file > and interpret it as a list of paths. ----- 8< --------- 8< --------- 8< --------- 8< --------- 8< ----- > Hopefully that clarifies the scenario a bit, even if it is far from a > concise explanation (I did edit this mail multiple times for clarity and > brevity, though, as I do with pretty much all of my mails). Certainly it does help. Thanks. I wonder if it makes sense to keep a copy of the bulk of your response in t/ somewhere, and refer to it from t/README, to help fellow non-Windows developers to avoid breaking tests on Windows without knowing.
