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

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

[Konstantin Kharlamov]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

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.

It might be useful to make a function to do the same within a git-repo,
but for now let's have at least a function that does that within a
file.

1:
https://emacs.stackexchange.com/questions/80361/when-merging-conflicts-in-smerge-mode-how-to-select-mine-for-all-conflicts

[-- Attachment #2: 1.patch --]
[-- Type: text/x-patch, Size: 2139 bytes --]

From 1702d7c0f782a8e18b2539194a5b276707181353 Mon Sep 17 00:00:00 2001
From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Date: Sat, 17 Feb 2024 12:43:02 +0300
Subject: [PATCH] smerge-mode: add a function to resolve all conflicts in a
 file

* lisp/vc/smerge-mode.el (smerge-resolve-all-in-file-to): a new
interactive function to resolve all conflicts in a file.
---
 etc/NEWS               |  6 ++++++
 lisp/vc/smerge-mode.el | 21 +++++++++++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index 9bdc3af5e71..b7a48412f4f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1170,6 +1170,12 @@ Similarly to buffer restoration by Desktop, 'recentf-mode' checking
 of the accessibility of remote files can now time out if
 'remote-file-name-access-timeout' is set to a positive number.
 
+** Smerge mode
+
+*** New interactive function 'smerge-resolve-all-in-file-to'.
+Allows to resolve all conflicts inside a file in preference of 'upper'
+or 'base' or 'lower'.
+
 ** Notifications
 
 +++
diff --git a/lisp/vc/smerge-mode.el b/lisp/vc/smerge-mode.el
index a16c7871ff9..c32410bcb15 100644
--- a/lisp/vc/smerge-mode.el
+++ b/lisp/vc/smerge-mode.el
@@ -714,6 +714,27 @@ smerge-keep-upper
   (smerge-keep-n 1)
   (smerge-auto-leave))
 
+(defun smerge-resolve-all-in-file-to (to-keep)
+  "Resolves all conflicts inside a file in preference of TO-KEEP.
+
+TO-KEEP decides which part to keep and is one of `upper', `base',
+`lower'".
+  (interactive
+   (list (completing-read "Keeping: " [upper base lower])))
+  (let ((resolve-func
+         (pcase to-keep
+           ("upper" 'smerge-keep-upper)
+           ("base"  'smerge-keep-base)
+           ("lower" 'smerge-keep-lower)
+           (_ (error "Unknown resolution argument!"))))
+        (num-chars-before (point-max)))
+    (save-excursion
+      (goto-char (point-min))
+      (while (ignore-errors (not (smerge-next)))
+        (funcall resolve-func)))
+    (when (= num-chars-before (point-max))
+      (message "No conflicts were found"))))
+
 (define-obsolete-function-alias 'smerge-keep-mine 'smerge-keep-upper "26.1")
 
 (defun smerge-get-current ()
-- 
2.43.0

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

[Eli Zaretskii]

> 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.

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.

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

[Konstantin Kharlamov]

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.

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

[Andreas Schwab]

On Feb 19 2024, Konstantin Kharlamov wrote:

> 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 think what you actually want is the 'ours'/'theirs' options of the
merge strategy (available to both the ort and recursive strategies).

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 13:25 +0100, Andreas Schwab wrote:
> On Feb 19 2024, Konstantin Kharlamov wrote:
> 
> > 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 think what you actually want is the 'ours'/'theirs' options of the
> merge strategy (available to both the ort and recursive strategies).

Oh, thanks for mentioning, I didn't know! So… how do I use them?

So, a usual workflow:

1. `git rebase -i HEAD~4`
2. do some edits
3. `git add -u && git rebase --continue`

*boom* I get conflicts and I want them to be solved in preference
"theirs". What command do I call here?

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

[Andreas Schwab]

On Feb 19 2024, Konstantin Kharlamov wrote:

> On Mon, 2024-02-19 at 13:25 +0100, Andreas Schwab wrote:
>> On Feb 19 2024, Konstantin Kharlamov wrote:
>> 
>> > 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 think what you actually want is the 'ours'/'theirs' options of the
>> merge strategy (available to both the ort and recursive strategies).
>
> Oh, thanks for mentioning, I didn't know! So… how do I use them?

       -X <strategy-option>, --strategy-option=<strategy-option>
           Pass the <strategy-option> through to the merge strategy. This
           implies --merge and, if no strategy has been specified, -s ort.
           Note the reversal of ours and theirs as noted above for the -m
           option.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 13:33 +0100, Andreas Schwab wrote:
> On Feb 19 2024, Konstantin Kharlamov wrote:
>
> > On Mon, 2024-02-19 at 13:25 +0100, Andreas Schwab wrote:
> > > On Feb 19 2024, Konstantin Kharlamov wrote:
> > >
> > > > 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 think what you actually want is the 'ours'/'theirs' options of
> > > the
> > > merge strategy (available to both the ort and recursive
> > > strategies).
> >
> > Oh, thanks for mentioning, I didn't know! So… how do I use them?
>
>        -X <strategy-option>, --strategy-option=<strategy-option>
>            Pass the <strategy-option> through to the merge strategy.
> This
>            implies --merge and, if no strategy has been specified, -s
> ort.
>            Note the reversal of ours and theirs as noted above for
> the -m
>            option.
>

Sorry, I'm not following.

So, I just created an artificial conflict. Then I get these errors:

    λ git merge -X theirs
    error: Merging is not possible because you have unmerged files.
    hint: Fix them up in the work tree, and then use 'git add/rm <file>'
    hint: as appropriate to mark resolution and make a commit.
    fatal: Exiting because of an unresolved conflict.
    λ git add -u
    λ git merge -X theirs
    fatal: No current branch.

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

[Andreas Schwab]

On Feb 19 2024, Konstantin Kharlamov wrote:

> So, I just created an artificial conflict. Then I get these errors:
>
>     λ git merge -X theirs
>     error: Merging is not possible because you have unmerged files.

You need to pass it when you start the merge/rebase.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 13:44 +0100, Andreas Schwab wrote:
> On Feb 19 2024, Konstantin Kharlamov wrote:
> 
> > So, I just created an artificial conflict. Then I get these errors:
> > 
> >     λ git merge -X theirs
> >     error: Merging is not possible because you have unmerged files.
> 
> You need to pass it when you start the merge/rebase.

Oh, I see… Well, thank you, good to know it's there. Although that does
limit the application of these options, not sure I'll be using them too
often… Because you need to plan beforehand that you'll get a conflict
which you'll want to resolve in preference of theirs or ours. And AFAIK
ours/theirs may be swapped between different commands (I don't remember
which, maybe cherry-pick, but I'm not sure), so that leaves a margin
for mistakes with the cost of digging into git-reflog to get the older
version of the branch and then re-apply changes anew. So… I guess I'll
prefer Emacs's smerge functional for resolving conflicts, it's just
more reliable.

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

[Dmitry Gutov]

On 19/02/2024 14:03, Eli Zaretskii wrote:
> 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.

Like Andreas described, doing a merge using an "ours" or "theirs" 
strategy is something that people do on occasion.

Whether it's a good option to be able to do in smerge as well, I don't 
have a relevant experience to comment on, but the patch looks short 
enough, so the added complexity is minimal.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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.

Yeah, I'm not sure we need this.

It would be easy enough to provide a kind of prefix command
`smerge-apply-all-conflicts` which reads the next key and calls the
corresponding command in every conflict in the file.
It would generalize `smerge-resolve-all`.

I have needed such a thing in the past, but there are several ways to do
that already: beside telling Git beforehand how to resolve the
conflicts, you can also use things like

    C-x ( C-c ^ n C-c ^ u C-x e e e e e e e e e


- Stefan

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

[Andreas Schwab]

On Feb 19 2024, Dmitry Gutov wrote:

> Like Andreas described, doing a merge using an "ours" or "theirs" strategy
> is something that people do on occasion.

I did not talk about the ours stategy (and there is no theirs strategy),
only about the ours and theirs option of the ort and recursive strategy.
The difference is that the ours strategy completely throws away the
other side of the merge, whereas the ours/theirs options of the
ort/recursive strategies control only how conflicts are handled.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 15:17 +0300, Konstantin Kharlamov wrote:
> 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.¹

Well, I understand these two points do not sound like something
unsolvable with `git-checkout` theirs/ours options. It's just the
general workflow that I remembered offhand.

I don't remember the distinction down to technical details, only that I
stumbled upon that quite often (which I usually noted because I thought
theirs/ours checkout is gonna work but then it wouldn't; and then I had
to abort everything because I needed conflicts back lol).

I think this happens because git is often quite good in making conflict
as small as possible. So I think if you have case like this: 1. you
modify return value in older commit, 2. You do `git rebase --continue`,
3. you get conflicts because there're unrelated modifications in the
same hunks as `return`s; then you might get conflicts that only contain
lines you just modified and nothing else. So resolving every conflict
becomes trivially choosing "ours" (IIRC, I confuse theirs/ours)
everywhere; but you don't want to `checkout --ours`.

----------------

Incidentally, for me it feels like having the case where you want to
solve *all* conflicts in preference of either side happens more often,
then the case where you want to solve only *only one* conflict in
preference of either side. IOW, if I had to rate by frequency conflict
types I meet during my everyday work, it would be (in order: most
frequent to less frequent):

1. Conflicts requiring manual intervention to take changes from both
sides.
2. Conflicts, where all of them at once may be solved in preference of
theirs or ours.
3. Conflicts where some require manual intervention and some may be
solved in preference of either side.

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 10:31 -0500, Stefan Monnier wrote:
> > 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.
> 
> Yeah, I'm not sure we need this.
> 
> It would be easy enough to provide a kind of prefix command
> `smerge-apply-all-conflicts` which reads the next key and calls the
> corresponding command in every conflict in the file.
> It would generalize `smerge-resolve-all`.

Sorry, I'm not sure I understand… 😅 You want a function `smerge-apply-
all-conflicts` that would accept a prefix command instead of an
explicit parameter? If so, that would be almost the same as what I did,
except with non-intuitive usability. Or I misunderstand something.

> I have needed such a thing in the past, but there are several ways to
> do
> that already: beside telling Git beforehand how to resolve the
> conflicts, you can also use things like
> 
>     C-x ( C-c ^ n C-c ^ u C-x e e e e e e e e e

I fear to even try to decypher that combination. For the record, I have
lots of commands that I use situationally, but I do not care to
remember their bindings because it's easier to just call `M-x` and get
a smex menu with "last history" that fuzzily autocompletes by typing a
few characters.

As an example: I have no idea what binding a `smerge-vc-next-conflict`
has; more over, I don't even remember the full name of this function. I
just type `M-x next-con` or `M-x confli` and it pops up as the most
recent command with that infix.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> It would be easy enough to provide a kind of prefix command
>> `smerge-apply-all-conflicts` which reads the next key and calls the
>> corresponding command in every conflict in the file.
>> It would generalize `smerge-resolve-all`.
>
> Sorry, I'm not sure I understand… 😅 You want a function `smerge-apply-
> all-conflicts` that would accept a prefix command

No: `smerge-apply-all-conflicts` would *be* the prefix command.
Instead of a prefix `C-u 8` which causes the next command to be executed
8 times, your use `M-x smerge-apply-all-conflicts` to cause the next
command to be applied to every conflict in the buffer.

> If so, that would be almost the same as what I did,

I think so, yes.

>> I have needed such a thing in the past, but there are several ways to
>> do
>> that already: beside telling Git beforehand how to resolve the
>> conflicts, you can also use things like
>> 
>>     C-x ( C-c ^ n C-c ^ u C-x e e e e e e e e e
>
> I fear to even try to decypher that combination.

`C-x (` starts a keyboard macro
`C-x ^ n` is `smerge-next`
`C-x ^ u` is `smerge-keep-upper`
`C-x e` terminates the keyboard macro and repeats it immediately.
Every `e` after that repeats the keyboard macro.

> For the record, I have lots of commands that I use situationally, but
> I do not care to remember their bindings because it's easier to just
> call `M-x` ...

I like `M-x` too :-)


        Stefan

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 21:24 -0500, Stefan Monnier wrote:
> > > It would be easy enough to provide a kind of prefix command
> > > `smerge-apply-all-conflicts` which reads the next key and calls
> > > the
> > > corresponding command in every conflict in the file.
> > > It would generalize `smerge-resolve-all`.
> > 
> > Sorry, I'm not sure I understand… 😅 You want a function `smerge-
> > apply-
> > all-conflicts` that would accept a prefix command
> 
> No: `smerge-apply-all-conflicts` would *be* the prefix command.
> Instead of a prefix `C-u 8` which causes the next command to be
> executed
> 8 times, your use `M-x smerge-apply-all-conflicts` to cause the next
> command to be applied to every conflict in the buffer.
> 
> > If so, that would be almost the same as what I did,
> 
> I think so, yes.

I think I see, so you suggest a function that would apply resolution to
the next N conflicts. But unless I'm missing something, sounds like
this would be less useful. The "resolve all conflicts" function caters
to specific situation where you want all conflicts to be resolved in
preference of either side. Whereas making a function to do that to the
next N conflicts I don't see how it's better, given that:

1. I just don't see what usecase it solves. The case where you know
that exactly 2 next conflicts needs to be solved for "upper" but not
more? I don't remember stumbling upon such situation and there's a
reason for that: you either know beforehand that all conflicts are
solved "in preference of X", or they require manual intervention; in
the latter case having to solve them one by one means that you
typically don't look up next conflict before you figured out the
current one. 
   Also, it is rare to have even 3 full conflicts simultaneously in a
window, so even if you looked up next conflicts before solving them,
you're very unlikely to use the command with prefix more than 3.
2. I posted elsewhere in the thread a frequency list of types of
conflicts I usually see, and the case where there are simultaneously
conflicts of mixed type "manual intervention" + "preference to some
side" is just more rare than other two cases, in particular the one
where everything needs to be solved "in preference". So if we're
discussing whether to accept the new function based on the number of
people that are going to use it, then I think the "resolve all
conflicts" wins just because it's a more frequent situation.

> > > I have needed such a thing in the past, but there are several
> > > ways to
> > > do
> > > that already: beside telling Git beforehand how to resolve the
> > > conflicts, you can also use things like
> > > 
> > >     C-x ( C-c ^ n C-c ^ u C-x e e e e e e e e e
> > 
> > I fear to even try to decypher that combination.
> 
> `C-x (` starts a keyboard macro
> `C-x ^ n` is `smerge-next`
> `C-x ^ u` is `smerge-keep-upper`
> `C-x e` terminates the keyboard macro and repeats it immediately.
> Every `e` after that repeats the keyboard macro.
> 
> > For the record, I have lots of commands that I use situationally,
> > but
> > I do not care to remember their bindings because it's easier to
> > just
> > call `M-x` ...
> 
> I like `M-x` too :-)
> 
> 
>         Stefan
> 

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> No: `smerge-apply-all-conflicts` would *be* the prefix command.
>> Instead of a prefix `C-u 8` which causes the next command to be
>> executed 8 times, your use `M-x smerge-apply-all-conflicts` to cause
>> the next command to be applied to every conflict in the buffer.
[...]
> I think I see, so you suggest a function that would apply resolution to
> the next N conflicts.

No, that's not what I'm suggesting.  If you re-read the above I say
"applied to every conflict in the buffer" (rather than some specific N),
and I don't say "resolve" or anything like "resolution".

It's really doing the same as your patch, except that the command to
apply at each iteration is not limited to one of
`smerge-keep-(upper/base/lower)` (and that it's specified by hitting the
command's key binding rather than by choosing a string in the minibuffer).

BTW, your use of [upper base lower] as a completion table is both cute
and horrible at the same time :-)


        Stefan

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 22:15 -0500, Stefan Monnier wrote:
> > > No: `smerge-apply-all-conflicts` would *be* the prefix command.
> > > Instead of a prefix `C-u 8` which causes the next command to be
> > > executed 8 times, your use `M-x smerge-apply-all-conflicts` to
> > > cause
> > > the next command to be applied to every conflict in the buffer.
> [...]
> > I think I see, so you suggest a function that would apply
> > resolution to
> > the next N conflicts.
> 
> No, that's not what I'm suggesting.  If you re-read the above I say
> "applied to every conflict in the buffer" (rather than some specific
> N),
> and I don't say "resolve" or anything like "resolution".
> 
> It's really doing the same as your patch, except that the command to
> apply at each iteration is not limited to one of
> `smerge-keep-(upper/base/lower)` (and that it's specified by hitting
> the
> command's key binding rather than by choosing a string in the
> minibuffer).

Sorry, I'm not following 😅 The closest thing I see is you want a
prefix to each of smerge-keep-(upper/base/lower) commands to be added,
so that pressing a `C-u 0 smerge-keep-upper` would call the command for
each conflict in the buffer. But that seems both less discoverable and
more code to implement. But maybe I understood you wrong.

> BTW, your use of [upper base lower] as a completion table is both
> cute
> and horrible at the same time :-)

Hahah, why? 😅

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

[Konstantin Kharlamov]

On Tue, 2024-02-20 at 06:24 +0300, Konstantin Kharlamov wrote:
> On Mon, 2024-02-19 at 22:15 -0500, Stefan Monnier wrote:
> > > > No: `smerge-apply-all-conflicts` would *be* the prefix command.
> > > > Instead of a prefix `C-u 8` which causes the next command to be
> > > > executed 8 times, your use `M-x smerge-apply-all-conflicts` to
> > > > cause
> > > > the next command to be applied to every conflict in the buffer.
> > [...]
> > > I think I see, so you suggest a function that would apply
> > > resolution to
> > > the next N conflicts.
> > 
> > No, that's not what I'm suggesting.  If you re-read the above I say
> > "applied to every conflict in the buffer" (rather than some
> > specific
> > N),
> > and I don't say "resolve" or anything like "resolution".
> > 
> > It's really doing the same as your patch, except that the command
> > to
> > apply at each iteration is not limited to one of
> > `smerge-keep-(upper/base/lower)` (and that it's specified by
> > hitting
> > the
> > command's key binding rather than by choosing a string in the
> > minibuffer).
> 
> Sorry, I'm not following 😅 The closest thing I see is you want a
> prefix to each of smerge-keep-(upper/base/lower) commands to be
> added,
> so that pressing a `C-u 0 smerge-keep-upper` would call the command
> for
> each conflict in the buffer. But that seems both less discoverable
> and
> more code to implement. But maybe I understood you wrong.

Aaah, I think I get it. You want a command that would iterate through
conflicts and ask a user which solution side to apply?

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Sorry, I'm not following 😅 The closest thing I see is you want
>> a prefix to each of smerge-keep-(upper/base/lower) commands to be
>> added, so that pressing a `C-u 0 smerge-keep-upper` would call the
>> command for each conflict in the buffer. But that seems both less
>> discoverable and more code to implement. But maybe I understood
>> you wrong.

No, `C-u` `universal-argument` is a prefix command and it's the most
common *but* not the only one.  There's also `C-x RET c`
(`universal-coding-system-argument`), for instance, or `C-x 4 4`
(`other-window-prefix`) and `C-x 5 5` (`other-frame-prefix`).
I'm suggesting we define a new such prefix command.

> Aaah, I think I get it. You want a command that would iterate through
> conflicts and ask a user which solution side to apply?

But it asks only once.


        Stefan

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

[Konstantin Kharlamov]

On Tue, 2024-02-20 at 08:53 -0500, Stefan Monnier wrote:
> > > Sorry, I'm not following 😅 The closest thing I see is you want
> > > a prefix to each of smerge-keep-(upper/base/lower) commands to be
> > > added, so that pressing a `C-u 0 smerge-keep-upper` would call
> > > the
> > > command for each conflict in the buffer. But that seems both less
> > > discoverable and more code to implement. But maybe I understood
> > > you wrong.
> 
> No, `C-u` `universal-argument` is a prefix command and it's the most
> common *but* not the only one.  There's also `C-x RET c`
> (`universal-coding-system-argument`), for instance, or `C-x 4 4`
> (`other-window-prefix`) and `C-x 5 5` (`other-frame-prefix`).
> I'm suggesting we define a new such prefix command.
> 
> > Aaah, I think I get it. You want a command that would iterate
> > through
> > conflicts and ask a user which solution side to apply?
> 
> But it asks only once.

Okay, I see now. So a user calls the command, the command asks once
which side to apply, and then does that automatically for all other
conflicts. So… what's the difference compared to my patch, only that it
asks a user after going to a conflict? Or do you want it to
additionally stop at each conflict and ask a user if they want to apply
the "resolution"?

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> BTW, your use of [upper base lower] as a completion table is both
>> cute and horrible at the same time :-)
> Hahah, why? 😅

It's cute because it's concise and it kinda works.
It's horrible because vectors are not among the supported formats for
completion-tables: what you wrote will be assumed to be an obarray and what
you wrote is not a correct obarray.  The resulting behavior could be
surprising (e.g. include more entries than the one you wrote).


        Stefan

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

[Konstantin Kharlamov]

On Tue, 2024-02-20 at 09:03 -0500, Stefan Monnier wrote:
> > > BTW, your use of [upper base lower] as a completion table is both
> > > cute and horrible at the same time :-)
> > Hahah, why? 😅
> 
> It's cute because it's concise and it kinda works.
> It's horrible because vectors are not among the supported formats for
> completion-tables: what you wrote will be assumed to be an obarray
> and what
> you wrote is not a correct obarray.  The resulting behavior could be
> surprising (e.g. include more entries than the one you wrote).

Hahah, that's funny, thank you for explanation!

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

[Konstantin Kharlamov]

On Mon, 2024-02-19 at 20:07 +0300, Konstantin Kharlamov wrote:
> On Mon, 2024-02-19 at 15:17 +0300, Konstantin Kharlamov wrote:
> > 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.¹
> 
> Well, I understand these two points do not sound like something
> unsolvable with `git-checkout` theirs/ours options. It's just the
> general workflow that I remembered offhand.
> 
> I don't remember the distinction down to technical details, only that
> I
> stumbled upon that quite often (which I usually noted because I
> thought
> theirs/ours checkout is gonna work but then it wouldn't; and then I
> had
> to abort everything because I needed conflicts back lol).
> 
> I think this happens because git is often quite good in making
> conflict
> as small as possible. So I think if you have case like this: 1. you
> modify return value in older commit, 2. You do `git rebase --
> continue`,
> 3. you get conflicts because there're unrelated modifications in the
> same hunks as `return`s; then you might get conflicts that only
> contain
> lines you just modified and nothing else. So resolving every conflict
> becomes trivially choosing "ours" (IIRC, I confuse theirs/ours)
> everywhere; but you don't want to `checkout --ours`.
> 
> ----------------
> 
> Incidentally, for me it feels like having the case where you want to
> solve *all* conflicts in preference of either side happens more
> often,
> then the case where you want to solve only *only one* conflict in
> preference of either side. IOW, if I had to rate by frequency
> conflict
> types I meet during my everyday work, it would be (in order: most
> frequent to less frequent):
> 
> 1. Conflicts requiring manual intervention to take changes from both
> sides.
> 2. Conflicts, where all of them at once may be solved in preference
> of
> theirs or ours.
> 3. Conflicts where some require manual intervention and some may be
> solved in preference of either side.

Ok, did anyone order a case for "solve all to one side" that isn't
solvable with git's theirs/ours? Here, fresh from the bakery 😊

1. I edit a Makefile at hcl-mode¹ to try to introduce a separate option
for compiling tests and renamed the older `compile` one to `compile-
pkg`
2. While doing so I realize the Emacs call is wrong: it uses both `-Q`
and `-batch` options, whereas `-batch` implies "no init file". Strictly
speaking it implies `-q` not `-Q`, but it is very unlikely this
distinction is intentional. So I save the current changes and
interactively-rebase to the previous commit.
3. I remove `-Q` from all `-batch` calls and save it as a new commit
4. I do `git rebase --continue` and obviously I get conflicts

Now, git turns out to be very good in reducing conflicts, so it only
leaves me with the two lines that I change and nothing more from the
surrounding hunk. Now, since in the newer commit I don't have -Q
anymore, I know I want the newer version for all conflicts. But I can't
use `git --theirs/ours`, because that would return the `-Q`s that I
removed in the previous commit.

P.S.: with that said, in this case it was just one conflict, simply
because their Makefile is very small. But I hope you get the idea: if
there were more distinct lines where I'd removed `-Q` option both in
newer and older commits, they all would be solvable in preference of
the single side of the conflict.

1: https://github.com/hcl-emacs/hcl-mode