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.
Pass the git command to `jobstart()` as a string, not a list.
`jobstart()` does some kind of internal black magic to parse strings
like `'"/usr/bin/env bash" -l'`, whereas it would be impossible to pass
in an equivalent argument using a list.
Before, the value of `&shell` was being passed verbatim to `jobstart`
because no word splitting is done when the argument to `jobstart` is a
list. This would cause errors if the user's `&shell` were set to
something like `'/usr/local/bin/zsh -l'`.
This does not, however, fix another potential edge case, when the shell
command itself requires quoting (as per the example in the Neovim docs,
option E91). After doing some testing, it appears that `jobstart()` cannot
handle a quoted command, despite the recommendation in the manual (and
despite the fact that commands like `:terminal` work just fine with
double-quoted values for `&shell`). Whether this inconsistency is due to
a bug or something else, additional defensive action is probably needed.
For demonstration, try symlinking `/bin/bash` to `"./bad shell"`, and
inside Neovim setting `let &shell='"./bad shell"'. Everything works
fine, except `:call jobstart([&shell])` fails. Try various combinations
of quoting and calls to `jobstart()`, `split()`, and such: there seems
to be no way to get `jobstart()` to handle the quotes and spaces
properly without additional manipulation up-front.
Before this change, neovim's omnicompletion would always insert the
first completion option without allowing the user to choose any other.
Thanks to @lvht, @chemzqm, and @Shougo for help with this.
Closes#310, #311.
Reverts feature introduced in commit d59ac0394a
If you know your system's grep command does not support color, please use:
let g:gitgutter_grep_command = 'grep -e'
Reverts feature introduced in 5c23cadf57
In order to use an escaped grep, please replace
`g:gitgutter_escape_grep=1` with:
let g:gitgutter_grep_command = '\grep --color=never -e'
This change breaks up the determining of the user's grep command, and
the arguments it sends it.
Configuration is now:
let g:gitgutter_grep_command = 'grep --color=never -e'
This makes it easier for users to configure now, though not quite as
flexible.
Instead of creating two new temporary files every time a realtime diff is
performed, reuse the same two temporary files (per file extension).
This stops the plugin using hundreds of different temporary files.
Since the plugin now only uses a handful of temporary files we do not
need to wipeout the unlisted buffer created by vim for each index-blob's
temporary file.
In turn this means vim no longer needs hundreds of unlisted buffers, so
the next-available-buffer-number stays at sensible levels.
See #297.
The buffers being wiped out are temporary ones used to hold the contents
of a "real", unsaved buffer. Ideally vim wouldn't create them at all;
and in fact it seems sometimes vim does not create them (#258).
It would be good to find why the buffers are usually there but sometimes
not. In the meantime this change works around the problem.
This makes so that editing helpfiles directly triggers the gutters,
while keeping the default behaviour of editing help buffers (opened
with `:help stuff`) doesn't.
The `&&` and the `||` operators aren't available in fish.
The equivalents are `; and` and `; or`.
Also single parentheses are used for command substitution.
The fish equivalents are `begin` and `end`.
But they aren't needed here.
Most colorschemes (e.g. solarized) don't give any thought to the
SignColumn highlight group so generally the sign column is ugly.
With this change vim-gitgutter defaults to making the sign column look
like the line number column.
Solarized users no longer need `highlight clear SignColumn` in their
vimrc :)
To stop vim-gitgutter from overriding the SignColumn highlight, add this
to your vimrc:
let g:gitgutter_override_sign_column_highlight = 0
