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.
