Although the answer to use the cygwin git is viable, there are issue that the "git bash" version has improved, especially integration with the windows open-ssh implementation. I could be wrong about that and just haven't studied the cygwin implementation enough to fix it. YMMV. We still have the general class of problem for calling a windows executable from cygwin.
Three issues in this context (windows native gvim and git bash being my main concerns).
the path to file name arguments passed to the external (windows) command.
The environment the command finds itself in when it looks for configuration files (.vimrc/_vimrc/.gitconfig etc...). Since the Windows commands we are most interested in are Unix style, they mostly revolve around the $HOME variable for finding those config files. In cygwin shell that is going to be "/home/yournameisSue". But these programs are looking for the one you have in "C:/users/yourname_001" or some such.
PATH. This one is trickier. I'm going with the assumption that the Windows program will not be able to launch cygwin programs and so needs the original windows path, not the cygwin one. We have that available in $ORIGINAL_PATH. That sucks in that you can't easily do
:! somecygwincommand
from gvim, but that didn't seem to work anyway and I'm not solving that today.
My solution:
First set a variable with the full path windows style HOME. You can use forward slash just fine to simplify things, so the command "cygpath -m" can do that. I found a variable in my cygwin environment that has the proper directory name -- USERPROFILE. It has "C:\Users\myname_001" value. I set a new variable to hold this in .bashrc:
WINHOME=$(cygpath -m "$USERPROFILE")
$ echo $WINHOME
C:/Users/myname_000
Now I can start the non-cygwin git (like from git bash) or natively installed gvim like this (assuming they are in PATH. If not use a full path name version that cygwin understands!):
HOME=$WINHOME gvim $@ 2>&1 &
That at least makes it read my _vimrc file in my Windows home directory. Progress. But the command line argument processing is an issue when file paths are involved. Sure a relative path name like a file in the current directory works fine. When windows version of gvim starts up it asks the OS what directory it is in and doesn't know anything about the cygwin munging of it to /cygwin/c or whatever. But if you have a full path it gets messy.
I created a function to munge the argument list for paths. It creates a new array named _pathargs that we will use in place of $@.
pathargs() {
_pathargs=() # initialize empty array
for a in $@
do
if [[ "$a" =~ ^- || ! ( -f "$a" || -d "$a" ) ]]; then
# starts with a dash or is not a file or directory
_pathargs+=("$a")
else # is a file or directory so give a full windows path name
b=$(cygpath -m -a $a)
_pathargs+=("$b")
fi
done
}
Now my function to start gvim (which I named "v") and one to run a git bash git command are as follows. Note the setting of HOME and PATH before calling the windows executable. This syntax "exports" those environmental variables for the command that is executed without touching the ones running in your shell:
export WINHOME=$(cygpath -m "$USERPROFILE")
alias cdwh='cd $WINHOME' # convenience alias
v() {
pathargs $@
# set HOME var to one gvim understands for finding config files like .vimrc _vimrc
HOME="$WINHOME" PATH="$ORIGINAL_PATH" gvim ${_pathargs[*]} 2>&1 &
}
git() {
pathargs $@
# function to have same name as executable, so use "command" to protect
# against recursive call of the function itself
HOME="$WINHOME" PATH="$ORIGINAL_PATH" command git ${_pathargs[*]}
}
It all seems to work; however, if you have installed "git" with cygwin setup it will be in your path before the git bash (windows) version. In that scenario you will need to give the full path of the git executable in the function definition in lieu of using "command git". Remember to use a variant of it that cygwin understands.
HTH