Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> writes: > As you surmised, cygwin does not have this feature. On cygwin you are > encouraged to use the cygpath utility in scripts. (Also, cygwin does > provide an API to convert to/from POSIX/win32 paths from your own > programs. eg. cygwin_conv_to_[full]_win32_path() and cygwin_conv_to_\ > [full]_posix_path().) > ... > Just as an exercise, I created a script to use the windows PSPad editor > (included below), using it to create a commit and also run this rebase: > > GIT_EDITOR=pspad git rebase -i master uname > > Both git commands launched the editor (and completed their task) just fine. So where does the above leave us? Your message showed a way to "solve" it without changing git, but the presense of workaround alone is not a good reason not to change git, if the change makes things better without breaking other things. I'd like to know if Steven's patch breaks Cygwin users in other ways. Steven's message showed that spawning Cygwin programs and feeding paths in $GIT_DIR to them would not be broken if we start giving GIT_DIR as a Windows style path inside shell scripted Porcelains. But will there be other things that get broken by the change? An example of what would worry me is that we define has_drive_prefix() only for compat/mingw.h, so if somebody exports GIT_DIR back to call the binaries from scripted Porcelains, it is likely that it would break git running on Cygwin, where it expects only posix-style paths. Upon seeing C:/foo/bar.txt, it will start saying "Ah, that is a relative path" and may end up adding the $(pwd) in front when it needs to know its absolute path. -- 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