> If one branch has a commit and the other branch doesn't, merging them will mean that the commit is there. If one branch has the commit while the other branch

> If one branch has a commit and the other branch doesn't, merging them will mean that the commit is there. If one branch has the commit while the other branch has the commit and a revert for that commit, merging will mean it will be reverted. See, I fundamentally disagree that this is what I wanted. When I merge my thing with change x into head I expect to see my changes actually go in. Not to see commits retroactively added to head. The merge was the action, not some weird rewriting of historical order of events. > The biggest trick to understanding git is to learn to think in commits rather than file content. Ok, I'm starting to see what you meant. (I didn't understand this until the second part and my being confused as heck)