Re: easily use meld 3-pane view to review merge commits?

[Britton Kerin <britton.kerin@gmail.com>]

On Sun, May 4, 2025 at 1:00 AM Johannes Sixt <j6t@kdbg.org> wrote:
>
> Am 03.05.25 um 23:55 schrieb Britton Kerin:
> > I like how git-mergetool can use meld with 3 pane view to see merge conflicts:
> >
> >   git mergetool --tool=meld
> >
> > I'd like to use the same sort of view to see already-committed merges,
> > but I didn't find an easy way to do it.  It seems like git-diff,
> > git-difftool and git-show are oriented entirely towards diff or 2-pane
> > view rather than diff3/3-pane that git-mergetool uses.  Did I miss the
> > existing functionality somehow?
>
> I see a conceptual inconsistency with the desire to use a 3-pane view
> with a merge commit.
>
> 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.

At least meld via git-difftool (e.g. via git `mergetool --tool=meld` defaults to
showing $LOCAL, $BASE, and $REMOTE.  I think this is the right default,
but others prefer to see $MERGED from the start.  It's this configuration
with BASE that has an obvious symmetric arrangement for review of an
existing commit, and it's LOCAL, MERGED (the final form), and REMOTE.

> 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

Not that I know of.

> 2-parent merge commits be special-cased?

> That was the devil's advocate speaking. 2-parent merge commits are
> common enough that some merge tool support could make sense, but we
> should be aware that there is a conceptual hurdle.

Agreed.  Of course all merges can be decomposed into successive 2-parent
merges, and I suspect there are a lot of other paranoid people like myself
who always do it that way in large part because it's much easier to see what
happened after the fact that with octopus merges.

As I said I agree that wedging this into git-difftool isn't necessarily a good
idea, but it would be nice if it was available somewhere.  What I have
now as an answer to

https://stackoverflow.com/questions/79599180/show-a-git-merge-commit-in-three-panel-form-in-meld

is enough for me but obviously needs more work (to handle trees, various
diff3 renderers, etc.) but if that straightforward work got done would it be
a worthwhile addition to the toolbox?

Britton