On Sun, May 4, 2025 at 1:00 AM Johannes Sixt <j6t@xxxxxxxx> 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
