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 @^! > 21f5a4b9fee4f12e7793919f65361d2c16f7d240 > ^14bd840c1d591c9dc066ed1aab59b5ec14d502bb > ^944af379480826764f2f31b67848e2885b95b4a6 > > 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 > ^14bd840c1d591c9dc066ed1aab59b5ec14d502bb > ^944af379480826764f2f31b67848e2885b95b4a6 > > 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. Greetings, Eckhard
