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
If g:fugitive_result is defined during the User FugitiveChanged event,
one can trigger a custom behavior based on the arguments in .args or the
output in .file.
References https://github.com/tpope/vim-fugitive/pull/1015
Since this user event can error or otherwise interrupt us, run it as
late as possible. Also rearrange a bit so that a user error won't
cascade to "missing :endif".
If Vim is 100 columns wide, and we echo a string exactly 100 characters
long, Vim will insert a line break that a terminal wouldn't. This is
particularly noticeable with progress bars that Git erases with a screen
width's worth of whitespace. Work around this by decreasing the number
of columns by 1.
Apparently, both job_status() == "dead" and ch_status() == "closed"
isn't enough to guarantee all callbacks have run. One last sleep seems
to do the trick, but let's also add a sanity check because this can
cause confusing, hard to debug behavior.
This makes the pager behave a better, allowing the -- More -- prompt to
actually display and not dropping output if the process exits while
there's a backlog. An additional benefit is if Git for some reason
produces additional output while GIT_EDITOR is running, that output will
be buffered rather than interrupting the user.
The extracted s:RunTick() helper changes the Vim behavior to check the
process status after waiting as well as before. This brings it in line
with how Neovim's jobwait() appears to work.
The zero argument :echo after the final s:RunEcho() clears up some weird
draw issues with `:Git command|someothercommand`.
References https://github.com/tpope/vim-fugitive/issues/1717
Tim Pope