The idea is that g:fugitive_git_command is for user facing commands and
suitable to be changed to something like "hub", while
g:fugitive_git_executable is for low level internals.
If %TEMP% is set to a short path (e.g. "C:\LongDi~1") then tempname()
will return a file name that contains that short path. If that path is
later used as key for entry in s:temp_files dictionary, that entry won't
be found in BufNewFile,BufReadPost events because <afile> is expand()'ed
before it is used as a key for s:temp_files.
In the end, user gets cryptic error message about
"C:\LongDirName\VI12345.tmp.fugitiveblame" not being a git repository
when he tries to open a commit in Gblame window.
To workaround that we expand paths of temp files when adding entries to
s:temp_files. Also, because expand() can't expand short path if it
doesn't exist in the file system, we have to extract the directory part
and expand it separately.
Old behavior: Follow remote/branch to local branch to upstream,
wherever that happens to live.
New behavior: Open branch at remote, without further resolution.
Fixes#871
It is valid - though odd - to open a file at `some//path`. In that case
the current check for fugitive buffers matches and changes &path
unexpectedly. A stricter match against `://` prevents this.
For some locales like de_DE.UTF8 the text of `git status` contains multi-byte characters.
This change allows a subsequent file name to be matched correctly .
This removes the fugitive_utility augroup, and allows for something like
the following:
> vim --cmd 'au User Fugitive Gbrowse!' path/to/file
Without this patch the user's User autocommand would be run before
fugitive's, and therefore the commands would not be defined already.
When using a helper script to make Windows Vim work with Cygwin Git, arguments
containing spaces don't survive being passed through "cmd /c" to this script
and are decomposed into several tokens.
Just use "%x20" instead of spaces in the pretty format to avoid the problem.
