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.
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.
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.
Not all versions of grep support the --color flag. This checks the
output of grep --help when building the grep command and avoids using
flags that aren't compatible with the version present.
Fixes#234.
`git diff` doesn't perform EOL conversion on stdin, causing it to
mistakenly flag every line as having changed when the working tree uses
a different EOL than the blobs. Writing the buffer to a temporary file
and diffing against that avoids this issue.
Fixes#232.
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.
