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

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

[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 asked about this on stackoverflow and made an answer with a script also:

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

If there isn't any existing automatic way to inspect merge commits in
this way I'd like to improve this script and turn it into git-meld3 or
something.  It's tempting to think it could be wedged into the
existing diff-oriented architecture of git-diff/difftool/show but the
result would probably be too confusing to be useful.

Britton

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

[Johannes Sixt]

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.

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?

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.

-- Hannes

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

[Britton Kerin]

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

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

[D. Ben Knoble]

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