I'm not sure if this should trigger every time the buffer is loaded, or
only on the initial split. Arbitrarily pick the latter for now.
References: https://github.com/tpope/vim-fugitive/issues/1828
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.
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.
The previous implementation for <cfile> didn't handle <cfile>:h
correctly. May as well support the rest of the gang while fixing this.
Note that unlike for % and #, these can return a commit in addition to a
file name. Use a ":." expansion, as in "<cfile>:.", to get the
corresponding work tree file.
Use 3 characters of the commit hash rather than 6, limiting the maximum
total declarations to 4,096 rather than 16 million. Avoid color
components lower than 0x20 and higher than 0xdf to help avoid colors
that blend into the background, light or dark. And for the terminal,
replace the use of CSApprox with a simple usage of the 6x6x6 color cube
found on 256 color terminals. CSApprox aims to provide accurate
replication of the input colors, whereas our goal is simply to use all
colors in roughly equal amounts.
The use of --theirs for Unstaged and --ours for Staged was based
entirely on the way conflicts were represented in git status --short,
except, that's backwards, the staged column contains our side of the
merge so discarding it should use --theirs. I never noticed because I
don't use this feature.
Fixing this is guaranteed to burn anybody who learned the whole
behavior, so let's promote 2X and 3X to official status, and require
opting in to the flipped default.
Also, since --ours and --theirs only touch the worktree, the correct
analogous operations for deletion is *not* git rm, but rather to remove
the worktree file directly. So let's do that, and add it to 2X and 3X
too.
Closes https://github.com/tpope/vim-fugitive/issues/1699
References https://github.com/tpope/vim-fugitive/issues/1648
Use temp buffer for output of any command for which the Git
configuration option of pager.<command> is true. Avoid using a temp
buffer if the value is false, even for commands like "show" where we
normally would. If the configuration value is present and can't be
interpreted as a Boolean, punt to a :terminal where Git will invoke it
directly.
Generate and use custom config dictionary that includes -c values passed
to :Git. This enables `:Git -c pager.status status` to correctly use a
pager.
Paginate "config", "branch", and "tag" for certain argument lists,
matching the logic found in the Git source code as closely as possible.
These 3 commands were identified as having special pagination logic by
the presence of the DELAY_PAGER_CONFIG flag on their definitions in
git.c.
Paginate "am --show-current-patch".
References https://github.com/tpope/vim-fugitive/issues/1415
The --paginate option to Git forces it to use $PAGER rather than its own
configuration, so it makes perfect sense for Fugitive to take on the
role of the pager.
This also removes the same behavior for --no-pager, allowing the command
to run with :! instead. I really don't like sudden backwards
incompatible changes like this, but the old behavior was based on a bad
understanding of how these options work, and I'd rather rip the band-aid
off sooner rather than later.
