From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs Subject: bug#69220: [PATCH] smerge-mode: add a function to resolve all conflicts in a file Date: Mon, 19 Feb 2024 20:07:41 +0300 Message-ID: References: <865xykr79f.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15560"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.50.3 Cc: 69220@debbugs.gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 19 18:09:04 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rc78Z-0003rq-JZ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Feb 2024 18:09:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rc78G-000634-9M; Mon, 19 Feb 2024 12:08:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rc78E-00062T-2r for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 12:08:42 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rc78D-0000HE-QT for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 12:08:41 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rc78Y-0003st-1b for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 12:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Feb 2024 17:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69220 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 69220-submit@debbugs.gnu.org id=B69220.170836252314886 (code B ref 69220); Mon, 19 Feb 2024 17:09:02 +0000 Original-Received: (at 69220) by debbugs.gnu.org; 19 Feb 2024 17:08:43 +0000 Original-Received: from localhost ([127.0.0.1]:43318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rc78E-0003s0-GS for submit@debbugs.gnu.org; Mon, 19 Feb 2024 12:08:42 -0500 Original-Received: from forward502b.mail.yandex.net ([178.154.239.146]:41346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rc789-0003ro-UZ for 69220@debbugs.gnu.org; Mon, 19 Feb 2024 12:08:41 -0500 Original-Received: from mail-nwsmtp-smtp-production-main-59.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-59.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:319b:0:640:ce08:0]) by forward502b.mail.yandex.net (Yandex) with ESMTPS id 8BA955E533; Mon, 19 Feb 2024 20:07:44 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-59.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id g7UNddDSluQ0-uHg3NGhd; Mon, 19 Feb 2024 20:07:43 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1708362463; bh=9rCtJW0buWgls1xpXP7w1sImMCkrpg39P2HEneD8vWo=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=p9u8hZ8HPQLMuRSBCs2OYo4wKkMrKIacCeHjmCr/vgB8jySfwOGL8D25lMf0ishSi avB/5tmGHSkzS+R4gA0jDEHzrk3UnclkvKwEu7ny/msh1gCOKK99BeokzspBckXnvV uUbcF+42BMM/J2D02Jzzwtejyy2N7/obciWRO8VQ= Authentication-Results: mail-nwsmtp-smtp-production-main-59.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280281 Archived-At: 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 > > > Date: Sat, 17 Feb 2024 13:16:14 +0300 > > >=20 > > > This implements a feature request from here=C2=B9 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. > >=20 > > 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. >=20 > 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. >=20 > Offhand I can tell at least two situations where it is needed; both > imply you have more than one commit on the branch: >=20 > 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.=C2=B9 > 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.=C2=B9 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.