This is much easier to deal with on other end, so if a :GBrowse provider
doesn't care about relative scp paths, allow them to ditch the scp
parsing entirely.
I don't think anybody liked this except for me. This brings :Gdiffsplit
one step closer to :diffsplit. The no argument version will probably be
removed eventually as well, but let's take it one step at a time.
After receiving feedback, I have decided that the forced direction is
what most people expect, so let's limit our :diffsplit matching to the
non-bang variant, for now at least.
When calling :Gdiffsplit with no argument, we always end up with the
work tree version as half of the diff, and it is helpful to position
that consistently. I generalized this to a consistent older versus
newer ordering when given an argument, but I don't think that has proven
very useful in practice.
This also introduces a minor behavior change where calling the bang
variant in the initial commit now loads an empty version of the buffer,
rather than falling back to the work tree.
When called with multiple modes, don't bail after the first disabled
mode.
This also restructures in a way to allow for transition to :exe s:Map(),
which will provide the correct line number on :verbose map <whatever>.
I deliberately omitted this event when adding FugitiveChanged, because I
figured it made sense for consumers to instead tap into BufWritePost to
see which file changed exactly. This would enable, say, vim-gitgutter,
to only refresh signs for the file that actually changed, rather
than for every file in the repository. In practice, however,
vim-gitgutter doesn't even bother with "in the repository", let alone
the exact file, opting instead to refresh every loaded buffer. I give
up.
Resolves: https://github.com/tpope/vim-fugitive/issues/1819
When given an argument list including --no-literal-pathspecs and a
buffer number, convert the buffer number to an argument by prepending
":(top,literal)" to the filename rather than "./". This allows
operating on file names that include special characters like "*" and
"?".
We use the Git dir for a few purposes:
* Direct filesystem access.
* Passing to Git as --git-dir=.
* Embedding in fugitive:// URLs.
* Referring to the repository without otherwise using it.
As a start to teasing these apart, introduce s:GitDir() to handle the
first 2 cases, s:DirUrlPrefix() for the 3rd case, and keep using s:Dir()
as a generic reference.
I was hoping to one day introduce a new, backwards incompatible API
here, but adoption has gotten widespread enough that I think we're stuck
with it. So let's go ahead and clean up some cruft that I've verified
is not in use in any known plugin. A couple of plugins do use
repo.rev_parse(), but only inside conditionals should never be
triggered.
Uses for this are limited, but it does allow for retrieving the raw URL
before resolution, or for getting other properties from the remote's Git
config.
Also, allow FugitiveRemoteUrl(browse_opts) to directly retrieve the URL.
This came out of a refactor to return the various URL components
separately. I'm not ready to merge that, but this change feels like
enough of an improvement to merge for its own sake.
In the same way Vim requires custom commands to start with an uppercase
letter, I'm starting to think we should self-impose the same constraint
on custom ++options. Also, let's throw "Git" in there, just to allow
this to be truly unique if necessary.
This also allows a special remote argument of ".git" to refer to the
local repository. A possible use of this would be a local gitweb
handler.
