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.
The core issue here is that on UNIX, fnameescape() always doubles
backslashes, while on Windows, it leaves them be. But it's a lot more
complicated than that, because Vim also avoids escaping other
characters, to minimize ambiguity. This can mostly be compensated for
by removing the corresponding characters from s:fnameescape, including
backslash itself. I'm a little worried that removing backslash will
have other implications, so keep an eye out for regressions here.
One character we can't remove is "!", because we need a way to escape
our own "the commit owning the current file" syntax. As a long term
strategy to address this, I'm introducing new !% and !# variations to
replace it. This is a bit on the ugly side, so I'm going to hold off on
committing to it as a documented interface until I've had more time to
muse on alternatives.
See also 6356bbc4a7, wherein I fixed a bug
with the exact same description. This suggests a change in Vim prompted
this new variation, but then again, there's no proof that I actually
tested my fix on Windows.
Resolves: https://github.com/tpope/vim-fugitive/issues/2071
These maps are not nearly as useful as they seem. Let's avoid tempting
newcomers to use them. I recommend to instead use <CR>, which shows the
change in context.
References: https://github.com/tpope/vim-fugitive/issues/2070
I'm quite eager to kill the "chomp" functions, as they're the last use
of system(). However, the successor, FugitiveExecute(), is only a year
old, and isn't a drop-in replacement. So let's bring them back for
awhile to avoid the need for a massive conditional to give backwards
compatibility.
The rest are pretty benign to support, so I guess they can stick around
until the band-aid is officially ripped off.
* On UNIX, jobs proceed normally, and exit with status 122.
* On Windows, jobs fail early, and no callbacks run.
* On Neovim, an exception is thrown.
Normalize the second and third cases to behave like the first, as that
was my assumed behavior during the initial implementation.
References: https://github.com/tpope/vim-fugitive/issues/1815
I figured "~" was unlikely to have legitimate uses, but it turns out
sourcehut uses it to prefix usernames in all of its URLs. Let's go with
a control character instead.
Resolves: https://github.com/tpope/vim-fugitive/issues/2021
Of the 8 :GBrowse providers listed in the README, 7 make no attempt to
handle URL encoding. So it makes sense for Fugitive to take
responsibility for this. By transposing "%" and "~" in API parameters
and then reversing the process on the generated URL, we can accommodate
both usages. This is transitional and will later be ditched in favor of
straightforward URL encoding.
References: https://github.com/cedarbaum/fugitive-azure-devops.vim/issues/3
This is technically backwards incompatible, but I've never seen a remote
with URL encoding in practice. (Also I don't think anyone is actually
using this function.) One can use .pathname if they need the encoded
version.
Might do this for everything but let's start here. I initially went
with backslashes for URLs because that's how Vim on win32 normalizes
buffer names, and figured it might simplify things like equality checks.
But Vim itself breaks in some places. Editing a `file://` URL doesn't
work if backslashes are in use, and Vim unescapes incorrectly when
constructing <q-args> (see 6356bbc4a7).
Work trees and submodules have two things that could be called the Git
dir: the directory itself, and the ".git" at the root of the work tree.
Introduce "fugitive_dir" as our name for the one we consider canonical.
This is still a garbage fire, but at least now the use of `.git/refs/`
paths has been relegated to the public interface. This also fixes a lot
of quirks, and hopefully doesn't introduce too many new ones.
This will enable functions like FugitiveFind() to use fugitive#repo() as
the optional second parameter, which should make transitioning to the
new API a bit easier to do incrementally.
The \s and \S atoms consider space and tabs to be the only valid
whitespace characters, while the [:space:] character class also includes
control characters like newline and form feed.
This is not and can never be 100% perfect. There's no way to work back
from a file like info/exclude COMMIT_EDITMSG to the work tree. So
core.worktree continues to be recommended.
References: https://github.com/tpope/vim-fugitive/issues/1920
Move "Unpushed" sections above "Unpulled".
Show commits that are unpushed anywhere when no upstream is set.
Provide czs map as :Git stash push --staged.
Support the MSYS Vim bundled with Git for Windows.
Turn remaining deprecated commands (:Gbrowse, etc.) into error stubs.
* Don't attempt to handle relative paths, as there's no guarantee the
current working directory is the one Vim was started with. In
practice, the only relative path I've seen is `.git/index`, which is
already the default and thus harmless to ignore.
* Cache the result of FugitiveVimPath(), to allow for slow
implementations.
Tim Pope