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.
Closes https://github.com/tpope/vim-fugitive/issues/686
For example, when running:
:Git add %
neovim throws the following exception:
E499: Empty file name for '%' or '#',
only works with ":p:h": terminal git add %
It is a result of the tabnew command, it creates a new blank tab where
"%" is empty.
This commit changes "tabnew" to "tabedit %" so you're still working on
the same file.
Once the command is done running the tab closes.
Previously, if there were untracked files inside an untracked folder,
:Gstatus would only show the new folder. Attempting to run a diff on the
folder would pass the directory name, which would result in Vim opening
a directory listing. This makes :Gstatus list all untracked files, even
if they're inside untracked folders. This requires Git >=1.4, and will
silently fall back to the old behavior on earlier versions.
Closes#605.
This is nothing more than a change in personal preference on my part.
It's particularly annoying when :Gstatus or the quickfix window is the
only other window open.
- Color were causing to appear strange characters in the result.
- These characters made impossible to navigate the results
- The solution was to disable colors while executing git grep
This is more reliable and fixes an issue where the syntastic location
list of the original file would be focused after `:Gdiff`.
Ref: c99f0ff06b (commitcomment-9434351)
* Provide :Gpush, :Gfetch, :Gmerge, and Gpull.
* Use -L to handle :Glog range.
* :Gcommit -v opens message in new tab.
* API for custom :Gbrowse handlers.
* Invoke :Browse if available to open URL.
* Colorize hashes in :Gblame buffer.
* Set cursorbind and nobuflisted in :Gblame buffers.
* :Gblame in blame buffer toggles buffer.
This implements the changes suggested in tpope/fugitive#415.
s:repo_configured_tree is now a global, s:configured_tree() that caches
the bidirectional relation between the worktree and the git_dir.
extract_git_dir() now uses that relation to check whether the
directories it scans are valid worktrees known by the repo at $GIT_DIR.
