From: Martin von Zweigbergk <martinvonz@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, Johannes Sixt <j6t@kdbg.org>,
"B. Stebler" <bono.stebler@gmail.com>, git <git@vger.kernel.org>
Subject: Re: Improving merge of tricky conflicts
Date: Thu, 21 Jan 2021 10:30:36 -1000 [thread overview]
Message-ID: <CANiSa6jsjrm-i+T1zSBMFqpUqy-PJpai39JtH47m=v1TO_fi4A@mail.gmail.com> (raw)
In-Reply-To: <YAmPnfb/KMlqimhH@coredump.intra.peff.net>
On Thu, Jan 21, 2021 at 4:28 AM Jeff King <peff@peff.net> wrote:
>
> On Fri, Jan 15, 2021 at 04:50:08PM -1000, Martin von Zweigbergk wrote:
>
> > > > I do this often enough to wonder if I should write a small "filter"
> > > > that I can pipe a whole "diff3" <<< ... ||| ... === ... >>> region
> > > > to and convert it into to diffs, but not often enough to motivate
> > > > me to actually write one ;-).
> > >
> > > I would definitely have found that useful before (usually when one side
> > > made a tiny one-line change and the other side deleted or drastically
> > > changed a huge chunk).
> >
> > FYI, I added something similar to Mercurial recently. Instead of two
> > diffs, it shows one snapshot and one diff. See
> > https://phab.mercurial-scm.org/D9551 for details. I've used it for a
> > few weeks and it seems to be working pretty well. The drawback is
> > mostly when you want to keep the side with the diff and ignore the
> > other side, since you'll then have to drop the lines prefixed with "-"
> > and then enter column-selection mode or something and delete the first
> > character on each remaining line.
>
> I've used the script I posted earlier in the thread several times in the
> last 6 months or so, by replacing the conflict markers in the file I'm
> resolving with the new output (basically "%!magic-diff3" in vim).
>
> It is helpful. My biggest complaint is cleaning up the diff from the
> marker after viewing it. In most cases where it's helpful, one side made
> a large change (say, deleting or moving a big chunk of code) and the
> other made a small one (tweaking one line in the moved chunk). The small
> diff is useful, but the big one is not. And then after having viewed it,
> I have to remove the whole big diff in my editor.
>
> (It sounds like yours _replaces_ the conflict marker with the diff,
> which is why you have to edit the diff. Mine is showing it in addition,
> so you have to delete the diff).
Yes, that's correct. It replaces the base and one side of the conflict
marker by a diff (and leaves the other side as a snapshot).
> I think rather than thinking of these as expanded conflict markers, it
> would probably be a more useful workflow to just look at the diff in a
> separate command (so just show the conflicts, not everything else, and
> just show the diff). I suspect it could be made pretty nice with some
> simple editor support (e.g., open a new buffer in the editor showing the
> diff for just the current hunk, or even the current _half_ of the hunk
> you're on).
At some point it seems better to delegate to a proper merge tool. You
said that you use vim, so I'm a little surprised that you use conflict
markers instead of using vimdiff. I don't use vim and I've never
really used vimdiff. I still use conflict markers, mostly out of
habit, but also because I usually run in a tmux session on a remote
machine. I feel like I should try to switch to meld.
next prev parent reply other threads:[~2021-01-21 20:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-21 23:29 Improving merge of tricky conflicts B. Stebler
2020-07-22 5:50 ` Johannes Sixt
2020-07-22 7:45 ` Jeff King
2020-07-22 17:26 ` Junio C Hamano
2020-07-23 18:25 ` Jeff King
2020-07-24 1:19 ` Junio C Hamano
2020-07-24 19:48 ` Jeff King
2020-07-24 20:18 ` Junio C Hamano
2021-01-16 2:50 ` Martin von Zweigbergk
2021-01-21 14:28 ` Jeff King
2021-01-21 20:30 ` Martin von Zweigbergk [this message]
2021-01-21 21:08 ` Jeff King
2020-07-22 20:17 ` Sergey Organov
2020-07-22 21:14 ` Junio C Hamano
2020-07-22 21:20 ` Sergey Organov
2020-07-23 18:26 ` Jeff King
2020-07-23 19:11 ` Sergey Organov
2020-07-23 21:39 ` Junio C Hamano
2020-07-24 5:15 ` Jacob Keller
2020-07-24 6:01 ` Junio C Hamano
2020-07-24 6:53 ` Sergey Organov
2020-07-24 20:30 ` Junio C Hamano
2020-07-24 22:11 ` Sergey Organov
2020-07-24 23:04 ` Junio C Hamano
2020-07-22 22:48 ` Bono Stebler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANiSa6jsjrm-i+T1zSBMFqpUqy-PJpai39JtH47m=v1TO_fi4A@mail.gmail.com' \
--to=martinvonz@gmail.com \
--cc=bono.stebler@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).