Re: [PATCH 2/2] git-sh-setup: work around Cygwin path handling gotchas

Junio C Hamano wrote:

Ramsay Jones [off-list ref] writes:

quoted

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)