Re: Merge commit diff results are confusing and inconsistent
- Date: Fri, 3 May 2019 21:12:31 +0200
- From: "Eckhard Maaß" <eckhard.s.maass@xxxxxxxxxxxxxx>
- Subject: Re: Merge commit diff results are confusing and inconsistent
On Fri, May 03, 2019 at 10:55:54AM -0500, Robert Dailey wrote:
> I have a merge commit. HEAD is currently pointing at this merge
> commit. To be exact, HEAD points to master, which points to the merge
> commit. My goal is to diff only the changes in the merge commit (stuff
> committed directly in the merge commit, such as conflict resolutions).
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.
> To start out, I learned about @^@, @^!, and @^-. @^! sounded like what
> I wanted. It gives me this output:
> $ git rev-parse @^!
> Perfect. This should give me just the diff of 21f5... and exclude
> everything else, right? So I did this:
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.
> $ git diff @^!
> However, I get *all* changes on the branch (second parent) and changes
> in the merge commit itself. Basically it acts as if I used @^-, which
> seems wrong to me. So to test another angle, I used the revisions
> output by rev-parse directly:
> $ git diff 21f5a4b9fee4f12e7793919f65361d2c16f7d240
> Interestingly, this showed me only the changes in the merge commit
> (21f5a4) and nothing else. Between this command and @^!, I feel the
> two are exactly the same. So why does @^! not work as I expect, but
> explicitly specifying the revisions does? What am I missing here?
> When I use @^! in `git log`, I do only see the merge commit and no
> other commits. So at least log is treating it correctly.
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.