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.
