CVS diff return code is 1 when the file differs from HEAD revision or
when there is an error (e.g. file is not under revision control),
while it is 0 (with an empty output) when the file is up-to-date.
The latter case was not handled, causing vim-signify to not recognize a
file under CVS when it did not have any change.
This reverts commit 6ab96c13937754e3078076c7fb6996a404f04459.
Unfortunately the situation is a tad more complicated than I thought. Revert for
now and have an eye on https://fossil-scm.org/forum/forumpost/834ce0f1e1
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
