We're trying to support two different Git syntaxes here that were never
meant to be mixed. We want :/foo/bar to be interpreted as the pathspec
:(top)foo/bar, but we want :% to be interpreted as the % file in the
index, even when % is /foo/bar.
Resolves: https://github.com/tpope/vim-fugitive/issues/2404
I think matching the Magit interface is probably a better use of P than
wrapping --patch. As a baby step in that direction, allow P to invoke
the same experimental behavior as "s" or "-".
Put all the stuff that actually updates the buffer together, so we can
soft reload without triggering autocommands or doing redundant work.
The reason for the previous ordering was to allow a bit of parallelism
while the diff commands ran in the background. Let's try to preserve
that for map definitions by running them in parallel to the status
command instead.
I'm not sure why 'nomodifiable' was set after BufReadPost. Let's try
the more natural ordering and see if anything breaks.
Ran into an issue where a running Vim (Neovim 0.9.5) consistently
treated a relative path not as the file in the current directory, but as
a different open buffer that matched the file name. The relative path
was just for cosmetics; let's switch to absolute so Vim doesn't butcher
it.
The Include directive behaves very literally. The old implementation
assumed a level of encapsulation that just doesn't match the actual
implementation.
Use `:Gedit https://github.com/...` (or any other URL supported by an
installed :GBrowse provider) to edit the corresponding `fugitive://`
URL. The dictionary g:fugitive_url_origins maps between homepage URLs
and local repositories:
let g:fugitive_url_origins = {
'https://github.com/me/my-repo': '~/Projects/my-repo'}
It also checks the remotes of the repository that the currently edited
buffer belongs to.
This is an experimental prototype. That means no documentation, and no
guarantees about behavior. In particular, g:fugitive_url_origins and
the current contortions to leverage the existing :GBrowse API will
likely be dropped once a better API has been developed.
References: https://github.com/tpope/vim-fugitive/issues/2223
The second reload was short-circuited by a reltime() check, so no big
deal, but it does get in the way when trying to make the reload
conditional.
References: https://github.com/tpope/vim-fugitive/issues/2207
Best I can tell the ability to pass a line number or tab number argument
has never been used.
Cleaning this up in anticipating of adding actually useful arguments,
and in anticipation of that, I'm preemptively making ReloadWinStatus()
blindly relay any arguments to ReloadStatusBuffer().
References: https://github.com/tpope/vim-fugitive/issues/2207
In particular, if the first :Ggrep result is a binary file, skip over
it. I'm also leaning strongly towards not filling in the filename field
at all for binary files, but I'll address that separately.
Almost included this in f75dbb1967, but
dropped it because it always equal to the current branch, guaranteeing
an empty log, and because unlike the "origin" default, it shouldn't
really happen in practice. However if a user screws up their config in
a way that forces it to happen, we should still try to avoid the same
"Push" header issue.
Verifying by URL is insufficient, as git clone --bare will create a
remote with a URL but not a fetch key, resulting in no refs in
refs/remotes/.
Resolves: https://github.com/tpope/vim-fugitive/issues/2129
If we defaulted branch.x.remote to "origin", then we should also default
branch.x.merge to the obvious choice. Otherwise we can end up in the
situation of a push ref without a pull ref, which leads to a rather
confusing "Push" header without a "Merge"/"Rebase" header.
References: https://github.com/tpope/vim-fugitive/issues/2129
My last attempt at this gave up and combined retrieving the list of
commits and rendering the list of commits into a single function. This
restores that distinction, albeit with a different approach, as I now
aim to use the same list of commits twice, in some circumstances.
This is mostly a refactor, but it fixes a bug where we could end up with
a push ref but not a pull ref when the underlying remote didn't exist,
resulting in a "Push:" header but not a "Pull:" header, which is
nonsensical. This changes it to produce a "Pull:" header but not a
"Push:" header, which is arguably still incorrect, but at least makes
logical sense.
If there are no remotes, then this section will always contain the
entire branch history, or a truncated version thereof. I want all
sections to be meaningfully bounded.
If commit maps are to made available in blame buffers, then the existing
behavior of editing the commit message in a horizontal split of a narrow
window isn't going to cut it. My ideal solution would be to create a
split that spans both the blame buffer and the original file, but I
don't think there's a practical way to do that, so I've instead settled
for using :topleft/:botright instead, as appropriate. The other natural
solution would be to switch to the original file and split there, but
that means we'd end up with a scroll-bound window with a mismatched
height, which behaves exactly as poorly as you would expect.
Furthermore, I've made the decision to extend this behavior to paginated
output windows (e.g., `:Git log`), but *not* to other window creation
commands like :Gsplit.
References: https://github.com/tpope/vim-fugitive/issues/2035
This doesn't actually work correctly as in a few places we deliberately
override a map. I'll accept a PR to bring it back, but it will need to
fix said issues. Until then, unmapping undesired maps is the
recommended solution.
Tim Pope