bug#3860: vc-svn calls "svn resolved" without permission

[Dmitry Gutov]

On 25.01.2021 00:36, James Y Knight wrote:

> I haven't used svn in years at this point, so I really don't care what
> happens with vc-svn anymore. But I had personally long ago worked around
> this bug with:
> (defadvice vc-svn-resolve-when-done (around dont-svn-resolve activate)
>    nil)

Fair enough.

> However, I will mention that I find the equivalent behavior in Emacs's Git
> integration just as bad -- for the same reason of it discarding important
> information! There's a reason that "git add" is a separate operation, and
> having emacs silently run that when doing a "save" operation destroys
> information, unexpectedly.
>
> I really think this behavior should _never_ have been made default
> behavior in _any_ VC mode. Discarding data is quite a bad default, and
> extremely unexpected from "save". But, hey, at least vc-git can be
> configured, so that's nice.
>
> (And, I'll note that it took me at least a _year_ to figure out that the
> broken behavior after resolving conflicts in Git was an emacs vc-git bug,
> and not Git itself having lost the ability to 3-way-conflict-diff the
> conflict resolution! It's incredibly non-obvious that emacs is breaking
> this!)
>
> I'm not the only one to complain about this, e.g.
> https://emacs.stackexchange.com/questions/51206/disabling-automatic-add-after-resolving-git-conflict
>
> For that matter, bug 20292 which added the emacs config option has
> multiple complaints about this behavior, as well...

"Multiple complaints" seems to be an overstatement: we have one question 
of SE, and one disagreement in the bug comments. The disagreement is 
from the current Git maintainer, which is significant, but still not a 
gospel, since VC tries to provide a "unified" interface to many VCSes, 
not just Git.

That said, I personally customize vc-git-resolve-conflicts to nil, and 
'C-x v v' now does resolve the conflicts all right (even though it 
doesn't refresh the vc-state of such buffers automatically). So nil 
works okay, and it would be my vote.

But the current behavior of that variable and its default value have 
been requested by Emacs maintainers, one former and one current. As 
such, I'll let the maintainers decide on whether the default can be 
changed here.