Taking the option that was historically a shell command and treating it
as a space-delimited argument list means that there's no longer any way
to include a space in an argument. Let's rectify that by reusing a
simplified version of the argument parser in s:SplitExpandChain(), which
handles both single and double quoted strings in a way similar to how
shells do it.
Of course, the ideal solution is to just use a list of strings to begin
with. Support for that is added here as well.
References: https://github.com/tpope/vim-fugitive/issues/1751
# This is the commit message #2:
squash! Accept argument list for g:fugitive_git_executable
When I first wrote this code, I believed push.default=upstream to be the
One True Way, and I used the upstream as the default branch when one
wasn't passed into :GBrowse. Since then, my preferred workflow has
shifted to push.default=current, with my upstream pointed at the
repository's integration branch (typically master), which means :GBrowse
effectively ignores our current branch, which is less than helpful.
This change eliminates :GBrowse's use of the upstream tracking branch
except in 2 scenarios:
* When push.default=upstream
* When the current branch has never been pushed (since using the current
branch would result in a 404).
This renders a lot of other version checks inside the plugin obsolete,
but I'm going to hold off on cleaning them up until I'm sure this change
is permanent.
I don't think the change that this reverts was necessarily wrong,
but this isn't the best time in the release cycle to play whack-a-mole
with unintended consequences.
Closes https://github.com/tpope/vim-fugitive/issues/1732
Previously, we would return a path from the current working directory in
this case, which was a good fallback for :Gedit but unhelpful for
general programmatic usage.
This appears to work fine in some setups, but has the same problems
as regular win32 in others. Most notably, for it to work properly with
the Vim included with Git for Windows, the experimental pseudo console
support must not be enabled. Lacking a method to distinguish between
the two cases, I see no better option than disabling it on all win32unix
installations.
Closes https://github.com/tpope/vim-fugitive/issues/1726
If a line number is given, browse to the commit on that line.
Otherwise, browse to the file, same as if called from the original
buffer.
It would probably make more sense to open the corresponding blame page
on providers that support it, but that will have to wait on an API
change.
References https://github.com/tpope/vim-fugitive/issues/1214
This makes :GBrowse fugitive://... work when the buffer name is from a
different repository. It doesn't solve the harder problems of making it
work with a regular filename, or making it not bail early when the
current buffer doesn't belong to a repository at all.
The previous implementation for <cfile> didn't handle <cfile>:h
correctly. May as well support the rest of the gang while fixing this.
Note that unlike for % and #, these can return a commit in addition to a
file name. Use a ":." expansion, as in "<cfile>:.", to get the
corresponding work tree file.
This is one of the more common conflicts people have with their own
maps, so make it available on "s" and "u". This roughly lines up with
the status buffer maps, which I think is as good of decision as any,
lacking a better mnemonic.
This race condition is there for any key press, but it's greatly
exaggerated by Vim's default one second timeout on Escape. This delay
also disqualifies Escape as the official interface to this feature, but
leave it as a DWIM alternative to CTRL-D for now.
Closes https://github.com/tpope/vim-fugitive/issues/1722
