Why merging hurts in Subversion but is easy in Git

Andreas Ericsson summed it up nicely in a post to the Git mailing list earlier today:

1. In SVN (and CVS), you're merging unknown changes into unsaved state. You haven't committed your changes to the repository before you merge, and you haven't (usually) looked at the upstream changes before you try to merge. Git doesn't have this problem (and neither does any other distributed version control system), since you first fetch changes from someone else and then merge them into an already saved state. When a merge conflict resolution goes wahoonie-shaped, you can easily restore either of the previously saved states with zero hassle.
2. Git has rerere, which records and reuses previously resolved merge conflicts, so you won't get the same merge-conflict more than once, if you enable rerere.
3. SVN (and CVS) won't remember which changes are already merged in, so they will fail horribly at repeated same-branch merges. Git (and other DAG-based SCMs) can and do calculate the merge-base for you so you'll never have to think about that yourself.