If fileformat is dos and eol is not set, then a '\r' (but without '\n')
will be written to the last line of temporary buffer file, which will
confuse git and make git think all lines are modified. Fix it by adding
'r' to all lines except the last one if fileformat is dos and eol is not
set.
Suggested-by: Andy Stewart <boss@airbladesoftware.com>
Signed-off-by: Adam Tao <tcx4c70@gmail.com>
If a file is subject to a clean/smudge filter, it is impossible to stage
an individual hunk. Therefore if the user tries to stage a hunk, ask
whether they want to stage the entire instead.
Determining whether a clean/smudge filter applies is done with:
git check-attr filter -- path/to/file
– and looking for "unspecified" (not to be) in the output. The result
is cached so that for a file which is not filtered (the common case),
staging multiple hunks only incurs the cost of the external call once.
See #796.
This tells git-show to output the smudged version of a file if a
clean/smudge filter is defined for it. In turns this allows us to diff
the buffer contents (which is smudged) against the reference version.
However patches cannot be applied.
See the man pages for git-show and gitattributes for more information.
See #796, #435.
If g:gitgutter_diff_base has been set and the file being processed does
not exist in that branch/commit, ensure that every line is marked as
added - this is how git-diff behaves.
Fixes#855.
In this context older vims are those without timer_start() and lambda.
The plugin always used to process the buffer at startup. Then in #734
an optimisation was introduced to defer processing at startup, to keep
vim's startup fast. However in this optimisation older vim's
unintentionally lost their startup processing altogether.
If the user has removed the "gitgutter CursorHold" autocommand, which
is the documented way to turn off automatic refreshing, calling the
autocommand at start up will fail. Use a timer instead.
This implementation also changes the processing delay to 1ms instead of
'updatetime'.
See #840.
