As of scrooloose/nerdtree@d36b793, it was recommended to use
NERDTree.root instead of deprecated NERDTreeRoot. Also, this command
seems to be recently removed since it was throwing an Undefined
variable: b:NERDTreeRoot when starting Vim.
Use `-range` instead of `-count` to prevent Vim from interpreting a
branch name starting with a number as a count, e.g. `:Gread 123-foo`
being interpreted as `:123Gread -foo`.
This is a really contrived feature, but I want to make it possible for
people to have their cake and eat it too when it comes to custom
repository URLs that redirect to GitHub.
If you call :Gdiff on a file that's also open in a separate tab, close
it, switch to another file, and call :Gdiff again, Vim thinks the first
file is part of a 3-way diff, despite no longer being displayed in a
window. Curiously, :diffoff! seems to work around this, despite both
the documentation and source code suggesting it merely iterates over
open windows.
Closes https://github.com/tpope/vim-fugitive/issues/534
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.
