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
