> From: Richard Stallman <r...@gnu.org>
> Cc: psm...@gnu.org, gnu-system-discuss@gnu.org
> Date: Fri, 08 Nov 2019 22:26:51 -0500
> 
>   > The only difference is that after resolving the conflicts you need to
>   > say "git commit", so that the conflict resolution is recorded in your
>   > local repository.
> 
> That would be easy enough, but I did not get that far.

Can you remember what stopped you?  Was that the fact that Emacs
turned on smerge-mode, or was it something else?

>   > This is already happening.  The merge conflict markers are identical,
>   > at least by default.  When you edit a file with the markers, Emacs
>   > automatically turns on the smerge-mode, which stages the files for
>   > commit when you save them after resolving the conflicts.
> 
> I have never used smerge mode, and when I was dropped into it without
> warning or explanation, I couldn't figure out what to.

It's a minor mode that simplifies handling of merge conflicts, so you
could just ignore it and edit the conflicted parts by hand.  That'd do
in the first approximation, although I'd urge you to look at the
mode's documentation, because it has some handy commands for moving
between conflicts and semi-automatically resolving them.

> Can I turn that off?  What would it do if it didn't go into smerge mode?
> Would it give me an ordinary file showing the conflicts in the CVS way?

Smerge mode is a minor mode, so I don't see why you'd want to turn it
off, it doesn't get in the way of your editing in any way.  If you
never invoke any of its commands, its only manifestation will be the
faces it puts on conflict markers and the conflicted parts of the
file.

You get an ordinary file with CVS-style conflict markers with or
without Smerge mode.  The markers are inserted by Git, so they are
there once Git detected a merge conflict.  In fact, it's by detecting
these markers that vc-git.el realizes the file you visit has merge
conflicts and turns on smerge-mode; see vc-git.el:vc-git-find-file-hook.

> If smerge mode is useful in this situation, how about making its use
> into an option supported for all back-ends for which conflicts are possible?

It already is used by all back-ends, and they all work the same wrt
conflicts, at the level we are talking here.  The Git back-end
additionally registers an after-save-hook that stages the file for you
if all the conflict markers were removed (which it takes to mean you
resolved all the conflicts).

Reply via email to