With `:Gdiff ^` on a file that has just been added, you would get an
error via `git rev-parse --verify`:
> fatal: Needed a single revision
The error message is clearer when not using `--verify`:
> fatal: Path 'X' exists on disk, but not in 'SHA'.
The behavior depends on if you use `:set hidden`, where the second
invocation works, as in will open an empty buffer - apparently since it
has been created as "a buffer with read errors" ("x" in `:ls!`) before.
Fixes https://github.com/tpope/vim-fugitive/issues/866.
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.
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.
If the previous window no longer exists when Gedit is called, the
attempt to change windows with 'wincmd p' fails and 'wincmd w' should be
used instead.
The option `status.showUntrackedFiles=all` used with `git status` for
`:Gstatus` might cause an error, which then causes fugitive to display an
empty status window / index file.
Redirecting the stderr output is useful in this case.
The generated command was:
git --git-dir=/home/user/.dotfiles/.git -c 'status.displayCommentPrefix=true' -c 'color.status=false' -c 'status.short=false' -c 'status.showUntrackedFiles=all' status
The error from git is related to submodules being moved to another
subdirectory, where the relative "gitdir" now does not exist anymore:
fatal: Not a git repository: vim/bundle.old.nobackup/CLEAN/colorscheme-base16/../../../.git/modules/vim/bundle/colorscheme-base16
While that's a Git / user error after all, fugitive should be more
helpful in that case by displaying the error.
It uses the 'shellpipe' setting to detect if '2>&1' is supported (Ref:
https://github.com/tpope/vim-fugitive/pull/661#issuecomment-120438667).
Closes#661.
