Combined stdout and stderr is what system() gives us, so the plugin was
built around it. But getting the same from jobs is annoying, so let's
eliminate all unnecessary uses of it.
Based on the prevalence of /usr/bin/env shebangs, I trust it is safe to
hard code this. Or at least, it's safer than trusting the user not to
create a script called env.
This shouldn't matter in this context since it's designed only to
provoke an error message, but fix it anyways so it stops setting off
mental alarm bells.
* Respect User and Port in addition to Hostname.
* Support globs and negations in addition to literal host matching.
* Parse global config file in addition to user config file.
* Handle Include declarations.
References: https://github.com/tpope/vim-rhubarb/issues/65
This is currently a valid assumption, but it boxes us in. Instead use
fugitive#Find('.git/'), which is guaranteed to return a path to an
actual directory.
Also use fugitive#Find('.git/refs/..') to determine the common
directory.
This correctly handles the case of multiple consecutive nulls (which I
don't think Git every produces in practice) and also the case of a bogus
newline at the end (which seems to happen with PowerShell).
References https://github.com/tpope/vim-fugitive/pull/1783
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).
Tim Pope