Before the plugin tries to diff a file, it checks whether git is
tracking the file. If git isn't tracking the file, it stops there and
doesn't display any signs. If git is tracking the file, the plugin
remembers so next time it can skip the check.
When I introduced asynchronous diffing for NeoVim (18b78361), I made a
refactoring mistake which caused the plugin on second and subsequent
runs [to always think git is tracking a file][1].
The non-realtime diffs – the ones you get when you save a buffer –
basically run `git diff FILE`. With an untracked file git returns
nothing and exits successfully. So although the plugin erroneously
thinks git is tracking the file, it gets an error-free, empty diff back
and so removes any and all signs. Which means that the bug doesn't make
any difference.
However the realtime diffs write the buffer's contents to a temporary
file, and write the file as staged in the index to a temporary file,
then run `git diff FILE1 FILE2`. To write the staged version of the
file we use `git show :FILE > TMPFILE`.
When `FILE` isn't known to git, `git show :FILE` exits with an error.
Unless, that is, [the filename contains square brackets and you're using
git v2.5.0+][2], in which case git exits successfully with empty output.
So if you're using git v2.5.0+, and you're editing an untracked file in
a repository, and the filename contains square brackets, the plugin will
think: git is tracking the file; the realtime diff is successful; the
file in the index is empty; so every line in the the working copy must
be an addition; hence a `+` sign on every line.
[1]: 18b7836168/autoload/gitgutter/diff.vim (L119-L121)
[2]: http://comments.gmane.org/gmane.comp.version-control.git/285686Closes#325.
"Undo" is a better name than "revert" because:
- "revert" sounds like it has something to do with `git-revert` but they
are entirely different;
- "undo" is consistent with vim's "undo": discarding changes and going
back to the original.
Maintain backwards compatibility and add deprecation warnings.
Closes#306.
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).
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.
