Assuming line 28 was deleted, the block header for a unified diff looks like:
+28,1 -27,0
This is true for usual suspects like `diff -U0` and `git diff -U0`, but
unfortunately not for Fossil. It would report this instead:
+28,1 -0,0
This lead our code to believe that line 1 instead of line 28 was deleted. And
maybe it's right about that. There does not seem to be a standard for patch/diff
output, but according to my knowledge Fossil is the only VCS doing that.
Anyway, this commit's change should make the detection of a deleted first line
work for every VCS again.
Fixes https://github.com/mhinz/vim-signify/issues/282
On Windows, Vim and Nvim can't work with mklink'ed paths. Issue an error message
and bail out before starting the actual job when the directory can't be changed.
Fixes https://github.com/mhinz/vim-signify/issues/279
Mercurial used to enable colors via an extension. Nowadays that is not true
anymore and `extensions.color=!` is rendered useless. Use the omnipresent
`--color=never` instead.
`defaults` is deprecated in favor of `aliases`. We use `aliases.diff=` to force
the use of the standard diff behaviour of `hg diff` which is the same as from
GNU diff. Otherwise an external diff tool could produce output that signify does
not understand.
Refrences #272
Commit cc2b17d462 removed the '&&' used to check whether the p4 info command succeeded. This caused incorrect invocation of the p4 diff command.
Add back the check for p4 info command success.
Prior to this commit the command invoked was:
p4 info >/dev/null 2>&1 env P4DIFF= P4COLORS= p4 diff -du0
This commit makes the invocation as:
p4 info >/dev/null 2>&1 && env P4DIFF= P4COLORS= p4 diff -du0
On Unix, many people use P4DIFF=colordiff to get colored diff output with `p4
diff`. But our diff parser doesn't expect these escape sequences used for
coloring.
We now simply use empty $P4DIFF and $P4COLORS to be on the safe side.
Reference:
36c7d22a69 (commitcomment-29924066)
Windows doesn't know about the `env` program.
Apart from that, using an external diff tool is not even needed anymore, since
`p4 diff` itself supports unified diffs nowadays.
Assume a hg repo below a git repo. `git diff` on a file managed by hg, will
return a successful exit value, but no output.
So, if we got a successful exit value from multiple VCS tools, and none of them
gave any output, keep them all as potential candidates. The next time Sy is run,
only these candidates will be tested again.
If one of them returns a proper diff, set b:sy.updated_by to that VCS and prune
all other candidates.
References #235
All VCS assume slightly different things where things have to be if you're in
this directory using that command etc.
Changing to the directory of the current file avoids many pitfalls.
This is only enforced for dynamically created signs, namely
g:signify_sign_delete and g:signify_sign_changedelete, if
g:signify_sign_show_count is on.
References https://github.com/mhinz/vim-signify/issues/105
Having default values for options that depend on another option's value is a bad
practice. Be more explicit:
g:signify_sign_show_text is ON by default
g:signify_sign_show_count is ON by default
So, people who want just background colors and no text at all in their signs
have to set both:
let g:signify_sign_show_text = 0
let g:signify_sign_show_count = 0
Before this change, only the first line was needed.
This also fixes a bug that happened with:
let g:signify_sign_show_text = 0
let g:signify_sign_show_count = 1
Removed lines wouldn't show a count whereas changed + removed lines would.
When you have nested repos of different VCS and you edit a file from the inner
repo, more than one VCS can return a valid diff. Only one VCS should return a
non-empty diff, though.
Once a non-empty diff is found, all other VCS get disabled to reduce overhead.
References #235.
Before this change, it was possible that a buffer was disabled, when Sy was run
more than once at startup, e.g. because of `BufEnter` and `FocusGained`.
The first call would start the detection and the second call would disable the
buffer, because the first call hadn't changed the VCS type from "unknown" yet.
