Adds support for when a symlink file <target> points to another file
<source>, where <srouce> is a file under Git version control.
Thanks to @Z1MM32M4N for work on this (see #209).
Also don't pass buffer number to functions when they can look it up
themselves.
Using buffer numbers also eliminates any ambiguity which might arise
from symbolic links, where you have potentially two names for a file.
Thanks to @Z1MM32M4N for work on this (see #209).
The only reason the realtime diff used `diff` instead of `git-diff`
previously was that I couldn't figure out how to do it in a way that
worked on Windows as well as Unix.
Previously vim-gitgutter generated context-free patches and applied
those to the index. However when staging a hunk situated after any
deleted lines, the line numbers on the patch were out by the number
of lines deleted, and without any context git would apply the patch
to the wrong part of the file in the index.
This commit ensure patches are generated with 1 line of context,
allowing git to adjust the line numbers appropriately and apply the
patch to the right location.
More lines of context would help git more to adjust line numbers; but
the more context we have the more we group together hunks we would
like to treat separately.
Before this commit some Windows users saw the command prompt pop
up briefly, and/or the taskbar flicker, every time the plugin ran.
Now the plugin will use xolox's vim-shell and vim-misc, if they are
available and we are on Windows, to execute external commands. Xolox's
clever plugins avoid the command prompt popup and taskbar flicker.
Windows users with those plugins installed can opt out by setting a
variable in their vimrc.
Many thanks to @suxpert for the initial code.
Note that line highlighting requires signs to be placed (because the
line highlight is simply an attribute of a sign). If the user doesn't
want to see signs in the sign column, but does want line highlighting,
then we make the signs in the sign column invisible.
If neither the signs in the sign column nor the line highlights are
needed (presumably the user just looks at the hunks stats) then we can
remove all signs, at which point Vim removes the sign column...unless
the "sign column always" option is set.
Since we start all external commands by cd'ing to the current file's
directory, we can use the file's name instead of its full path.
The exception is `git show :FILE` where we must use a path relative to
the repo root for maximum git compatibility. It turns out `git
rev-parse` takes a `--show-prefix` argument which makes our relative
path calculation far simpler.
Minimising files paths has these benefits:
- Easier to inspect the generated commands.
- Less opportunity for escaping problems.
- Eliminates possible mismatches betwen absolute paths generated by git
and absolute paths generated by Vim (crops up with msys/msys2 on
Windows).
Thanks to @suxpert for helping with this.
While I can't say I fully understand escaping rules for Windows, I
understand them better now than I did when I copied that code from
another plugin and hoped for the best.
As far as I can tell, this escaping code was written to be used when
manually constructing a system command to execute – which isn't how this
plugin is written. So this code shouldn't be here.
More recent versions of git support paths relative to current directory.
But for maximum compatibility we need to use paths relative to the
file's repo's root.
While it is aesthetically nicer to discard the unused output from `git
ls-files`, it isn't necessary. Discarding requires a shell redirection
which exposes us to vim's shell quirks; it's not worth it.
This bug meant that a realtime diff of a buffer which wasn't the current
one -- which happens during GitGutterAll() -- diffed the staged version
of the buffer against the current buffer's contents instead of the
buffer's contents.
