On Tue, May 7, 2019 at 9:10 AM Robert Dailey <rcdailey.lists@xxxxxxxxx> wrote: > Your example is very helpful. I understand what you're saying for > conflicted lines. But the "whatever the default merge resolution would > have been" doesn't exist, because there's no reality where line 1 in > color.txt can be something "automatic" (i.e. deduced by git). The only > reality for the merge commit is some hand-edited replacement to line > 1. So there is no "diff what I see with some alternate reality". > > The majority use case I'm interested in is seeing net-positive changes > that happen in merge commits. Normally I take for granted that merge > commits have nothing meaningful in them (meaningful here defined as > something unexpected for a merge commit). But what if someone makes a > poor decision and does some crazy refactoring in 1 file and amends it > into a merge commit? Let's also say that these changes are done to a > file that wasn't modified in any parent (say a unrelated.txt next to > your color.txt). Since neither parent cares about that file for the > purposes of the merge, I am trying to make sense of a revision > specification that can be used to see what they did to that file. > > Even ignoring that issue, the more concerning observation of mine is > that `diff @^!` produces any output at all. If you exclude both > parents, why do I see a diff for parent 2 (I see the complete diff of > the branch that was merged in)? > > Again, thank you for your example, you definitely made things very > clear for me. I see where the confusion is. And I think --cc is a good > way to get more context. At this point I'm just concerned about the > @^! behavior with merge commits & diff. Also I'm really confused how you got diff-tree to work. If I pick any arbitrary SHA1 of a merge commit in my existing repo's history, diff-tree produces only a SHA1 as the result: $ git diff-tree --cc bdd47a73d bdd47a73d18948aa46a8a7aa964543f0d989ffd4 I tried with just `-c` as well; same result.
