git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

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