Re: Merge commit diff results are confusing and inconsistent

[Robert Dailey <rcdailey.lists@gmail.com>]

I feel like you got hung up too much on exact wording of what I was
trying to describe. I do apologize I don't have the background to
explain things 100% accurately, especially at a low level. My
explanations are mostly intended to be as a user, based on what is
observable, and based on intent. I'll clarify in the quotes below...

On Fri, May 3, 2019 at 2:12 PM Eckhard Maaß
<eckhard.s.maass@googlemail.com> wrote:
> Hold on. Basically, there is no such thing as "committed directly" for a
> merge. You only have differences of the commit to its parents. What you
> aim for are changes that you cannot find in either preimage - and this
> can be observed best with the --cc option. Maybe also interesting would
> be -c for showing a comined diff and -m for showing diffs to parents
> after one another.

"Committed directly" here means that I made some changes, none of
which is part of a parent commit. Since no additional commits were
made following the merge, I assume that within the merge commit is
some type of diff. If I perform a merge, make some changes, and amend
those changes into the merge, in mind they ARE contained in that merge
commit. The underlying machinery doesn't matter here: This is the
observable state to the user.

Maybe the machinery, which I have no knowledge of or transparency
into, is important because it is affecting the behavior I'm seeing
when I do the diffs? Not sure...

> There shouldn't be "just the diff of <commit>" - you always have to tell
> where to diff it too, intrinsically Git does not save patches, but the
> whole content, after all.

I do understand this. But again, I'm not trying to be super technical
here. In plain english, all I'm trying to say is that I want to see
the changes that 1 commit introduces into the code base. So when it
comes to communicating the end result I want, I talk about it in terms
of 1 commit (the merge commit). The means to get that output is part
of my question and overall confusion. But as a baseline, I want to
clarify that I do understand a range is required input for the diff
command. In the case of merge commits, the way you specify the ranges
has many forms so I'm not sure based on the results I see, which one
is correct or what they all mean.

> Somebody else might know better why the diff actually produced the
> results you were looking for. I admit it is puzzling to me - I would
> have expected to error it out on the output of git rev-parse as there
> are three items.

Actually I can't think of any other command that can show me what
revision ranges translate to in "raw" commits. To me the raw forms are
always <sha1> and ^<sha1>, repeated as many times and in as many
orders necessary. Don't all of the vanity revision specifications
ultimately boil down to "from this parent" and "not from this parent"?