Junio C Hamano wrote: > Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> writes: > >> However, you could imagine adding code to accommodate external windows >> programs. If we limit ourselves to the text editor, for example, I could >> imagine something like the diff attached below to fix up the C based git >> programs. (You would need to make similar changes to the shell and perl >> scripts which launch the text editor). > > If you _only_ allow editors that understands windows style paths, your > patch may make sense, but doesn't it break editors that wants only POSIX > style paths? Yes. (If it wasn't clear, I included the code to show what I *didn't* want to see!). Cygwin built text editors will, of course, work fine with POSIX paths, but may also work with win32 paths as well. For example, vim supports win32 paths just fine (it's the *only* editor I tested). I would not be surprised if vim is not alone in that; I think it mainly depends on whether the editor attempts to "interpret" the parameter, or simply treats it as an opaque token to be passed straight to [f]open() [1]. Equally, I suspect some cygwin built editors will fail miserably (maybe they try to interpret the parameter as an scp-like url, say). I don't know and I'm not about to test every cygwin text editor to find out! So, in my opinion, adding code to explicitly support win32 paths, while possible, is likely to open up a can-o-worms (even if this support were opt-in via config). I would prefer that we don't go there. :-D ATB, Ramsay Jones [1] Which is why git already supports win32 paths to a certain degree. For example, the following will work as expected: $ git config --global core.excludesfile 'C:/cygwin/home/ramsay/.gitignore' (ie git will read and use the given .gitignore file without problem) -- 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