[ Jumping back in time ] Igor Lautar <igor.lautar@xxxxxxxxx> writes: >> Try this: >> >> commit=<sha1 of your merge commit> >> # Show diff with first parent: >> git diff "$commit" "$commit"^1 >> # Show diff with second parent: >> git diff "$commit" "$commit"^2 > > Yes, change is shown in commit^2, but actual file after merge does not have it. My commands had the wrong order. It should have been git diff "$commit"^2 "$commit". So, it showed the reverse of the modification introduced by the commit. If you see your change here, it means the change was reverted by the merge. My understanding of the situation up to now is: M |\ A C |/ B ($commit = M, $commit^1 = A and $commit^2 = B) Your file had a content (say, "old") at revision B. It changed content (say, to "new") at revision C, and at some point. A did not change it so it had the content "old". Then you merged, expected the merge commit M to get content "new", and actually got "old". So, your history looks like: M (old) | \ | `---. | \ A (old) C (new) | / | .---' | / |/ B (old) and "git diff C M" shows the diff between new and old. Something went wrong during the merge, I guess it used an ancestor (B above) that had "new" as content. I don't see how this happened (rather clearly, your history is more complex than my example above), but "GIT_MERGE_VERBOSITY=5 git merge" will show you which common ancestor was used, it may help. What's possible is that someone had already merged the branch containing "new", got conflicts, and resolved it in favor of "old" somewhere in the history of your master branch. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html