From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Fri, 09 May 2025 15:52:47 GMT
Subject: Re: easily use meld 3-pane view to review merge commits?
Message-ID: <CALnO6CDNPWWCWXvkpU0BUmaCzUfyZQhrtcxi1Nw_MBwVO6BKnQ@mail.gmail.com>
In-Reply-To: <50428492-8ece-426f-bfea-071b7bd2c374@kdbg.org>

On Sun, May 4, 2025 at 5:38 AM Johannes Sixt <j6t@kdbg.org> wrote:
> […]
> When merge conflicts are to be resolved, you have exactly 4 versions of
> a file to work with: base, ours, theirs, and the merge result. (Meld
> does not show the base and uses only 3 panes.) For this reason, it makes
> sense to have 3 panes in a merge tool, perhaps a forth for the merge
> base. That's it. You never need to have more than that.
>
> With a merge commit, you can have: the merge result, the first parent,
> and the second parent... and the third parent, the fourth parent, etc.
> You can have any number of versions to deal with.
>
> How does that fit into the picture? Can meld (or any other merge tool)
> have any number of panes and still work in a reasonable way? Why should
> 2-parent merge commits be special-cased?

Out of idle curiosity (with some Zsh shorthands):

for x (a b c d e); print -l 1 2 3 | shuf > $x'
vimdiff {a..e}

Turns out vimdiff can handle this and be reasonable, yep. Partly
because we can have arbitrarily many splits. It's still a bit
difficult to understand, though.

-- 
D. Ben Knoble