{"thread":{"id":"63414","subject":"Re: easily use meld 3-pane view to review merge commits?","startedAt":"2025-05-07T19:48:42Z","lastAt":"2025-05-07T19:48:42Z","messageCount":1,"participants":["Britton Kerin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"517515","messageId":"CAC4O8c-964C15ceOHYbk0=_DwpWfpbHgrvP46DoUeUtBbab1-g@mail.gmail.com","threadId":"63414","inReplyTo":null,"subject":"Re: easily use meld 3-pane view to review merge commits?","fromName":"Britton Kerin","fromEmail":"britton.kerin@gmail.com","sentAt":"2025-05-07T19:48:29Z","receivedAt":"2025-05-07T19:48:42Z","isPatch":false,"sender":{"key":"britton.kerin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7434164?v=4"},"body":"On Sun, May 4, 2025 at 1:00 AM Johannes Sixt <j6t@kdbg.org> wrote:\n>\n> Am 03.05.25 um 23:55 schrieb Britton Kerin:\n> > I like how git-mergetool can use meld with 3 pane view to see merge conflicts:\n> >\n> >   git mergetool --tool=meld\n> >\n> > I'd like to use the same sort of view to see already-committed merges,\n> > but I didn't find an easy way to do it.  It seems like git-diff,\n> > git-difftool and git-show are oriented entirely towards diff or 2-pane\n> > view rather than diff3/3-pane that git-mergetool uses.  Did I miss the\n> > existing functionality somehow?\n>\n> I see a conceptual inconsistency with the desire to use a 3-pane view\n> with a merge commit.\n>\n> When merge conflicts are to be resolved, you have exactly 4 versions of\n> a file to work with: base, ours, theirs, and the merge result. (Meld\n> does not show the base and uses only 3 panes.) For this reason, it makes\n> sense to have 3 panes in a merge tool, perhaps a forth for the merge\n> base. That's it. You never need to have more than that.\n\nAt least meld via git-difftool (e.g. via git `mergetool --tool=meld` defaults to\nshowing $LOCAL, $BASE, and $REMOTE.  I think this is the right default,\nbut others prefer to see $MERGED from the start.  It's this configuration\nwith BASE that has an obvious symmetric arrangement for review of an\nexisting commit, and it's LOCAL, MERGED (the final form), and REMOTE.\n\n> With a merge commit, you can have: the merge result, the first parent,\n> and the second parent... and the third parent, the fourth parent, etc.\n> You can have any number of versions to deal with.\n>\n> How does that fit into the picture? Can meld (or any other merge tool)\n> have any number of panes and still work in a reasonable way? Why should\n\nNot that I know of.\n\n> 2-parent merge commits be special-cased?\n\n> That was the devil's advocate speaking. 2-parent merge commits are\n> common enough that some merge tool support could make sense, but we\n> should be aware that there is a conceptual hurdle.\n\nAgreed.  Of course all merges can be decomposed into successive 2-parent\nmerges, and I suspect there are a lot of other paranoid people like myself\nwho always do it that way in large part because it's much easier to see what\nhappened after the fact that with octopus merges.\n\nAs I said I agree that wedging this into git-difftool isn't necessarily a good\nidea, but it would be nice if it was available somewhere.  What I have\nnow as an answer to\n\nhttps://stackoverflow.com/questions/79599180/show-a-git-merge-commit-in-three-panel-form-in-meld\n\nis enough for me but obviously needs more work (to handle trees, various\ndiff3 renderers, etc.) but if that straightforward work got done would it be\na worthwhile addition to the toolbox?\n\nBritton\n"}]}