git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Martin von Zweigbergk <martinvonz@gmail.com>
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 09:28:45 -0500	[thread overview]
Message-ID: <YAmPnfb/KMlqimhH@coredump.intra.peff.net> (raw)
In-Reply-To: <CANiSa6iV3WbS9VQdUQ-eF=dcz-mmQXvyckGJL8ZhpgFYc7U_TQ@mail.gmail.com>

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

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

-Peff

  reply	other threads:[~2021-01-21 14:37 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 [this message]
2021-01-21 20:30             ` Martin von Zweigbergk
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=YAmPnfb/KMlqimhH@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=bono.stebler@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=martinvonz@gmail.com \
    /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).