One thing that confuses me about Git (but I guess isn't unique to it) is what happens when you merge and "git show" the merge commit. It seems the classes of changes are:
- things that were the same on both sides so aren't in the diff
- things that were different but auto merged, and aren't in the diff
- things that were different, were auto merged, and are in the diff
- merge conflicts
But how did it distinguish the last 3? And how does it get so confident about #2 that it doesn't show them and there isn't a single command to show them?
When hg was more popular I knew someone working on Google Code who told me it was better because it didn't have rebases, but I'm pretty rebases and linear history are safer than this.
- things that were the same on both sides so aren't in the diff
- things that were different but auto merged, and aren't in the diff
- things that were different, were auto merged, and are in the diff
- merge conflicts
But how did it distinguish the last 3? And how does it get so confident about #2 that it doesn't show them and there isn't a single command to show them?
When hg was more popular I knew someone working on Google Code who told me it was better because it didn't have rebases, but I'm pretty rebases and linear history are safer than this.