I have a dictionary.

Conflicts will still happen with git, but “merge horror” no longer applies, for a couple of reasons (I come from a similar background, but switched to git in late 2005).

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 scm’s) can and do calculate the merge-base for you so you’ll never have to think about that yourself.