bug#69220: [PATCH] smerge-mode: add a function to resolve all conflicts in a file

[Konstantin Kharlamov <Hi-Angel@yandex.ru>]

On Mon, 2024-02-19 at 14:03 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Date: Sat, 17 Feb 2024 13:16:14 +0300
> > 
> > This implements a feature request from here¹ about having a
> > function to
> > resolve all conflicts simultaneously. Although question author
> > didn't
> > reply, but either way I think it's a useful functional. I needed it
> > so
> > many times, but before stumbling upon this question I just didn't
> > know
> > there are functions `smerge-keep-upper/base/lower`, and so ofc I
> > never
> > though of writing a new one that would apply them to all conflicts.
> 
> I use SMerge quite a lot, but never yet had a situation where the
> same
> resolution was applicable to all of the conflicts, let alone knew
> that
> in advance, before looking at each conflict.

Well, in Emacs it is allowed to create large commits with many
functional changes, which I think is why you never saw such functional
to be necessary.

Offhand I can tell at least two situations where it is needed; both
imply you have more than one commit on the branch:

1. You got a commit that does two different functional changes to a
hunk. So you want to split it. You do an interactive rebase to the
previous commit, then do one of the changes and create a commit from
it. Then you do a `git rebase --continue` and you get conflicts; but
you know beforehand exactly that you want it to be solved in preference
of the newer commit.¹
2. You noted, either yourself or as part of codereview, that one of the
older commits on the branch has a bug; but you know the bug is non-
existent in newer commits. So you fix it in the older commit, then upon
`git rebase --continue` you again know exactly that you want just the
newer version.¹

1: Actually, git provides a functional that should work for that
usecase; but in my experience it is more confusing than it's useful. It
is options `--theirs/ours`, i.e. `git checkout --theirs ./` and `git
checkout --ours ./`. But these options are problematic because instead
of resolving conflict in preference of `theirs` or `ours` they do a
complete checkout of the code from either of the branches. I can't
count how many times I was burned by trying to resolve conflicts with
these options and then was getting wrong code because together with the
conflicting part the options change everything else.

> I'm also guessing one could have the same effect by giving a prefix
> argument of suitable value to the conflict-resolution command.
> 
> Having said that, if this is deemed useful, why not?  Adding Stefan
> to
> the discussion, in case he has comments.  I'd also be interested in
> Dmitry's opinions.
> 
> Thanks.