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.
