Well then I REALLY don't get it. I can branch and merge all day in my scm if there aren't any conflicts. Is all the hype over git just because maybe the branch and merge commands are slightly simpler?
Git helped us out a lot in that it tracks content, not files. So where one person might do some cleanup that included renaming some files, and another might make some changes to the same files our previous source control system either choked or just ignored the changes.
Also, we were spending a very large amount of time waiting for merges to complete. Minutes. Lots of them. Git is lightning fast, and we spend a lot less cycles waiting (or context switching).
I would say the primary "hype" factor of git is because of local commits and all the infrastructure/features around them. Better server-side merges is just a nice bonus.
Having a local backup of the repo and making branching/merging very cheap reduces the friction in several VC operations. You can use techniques such as bisect* without cumulative network latency disrupting your train of thought. Also, when throwaway branches are cheap, you'll probably find you use them quite a bit more.
* For finding what commit introduced a bug, by binary search. Flag a revision as the last known good commit, then bisect will switch to a one in-between, wait for you to test and mark it as good or bad, then repeat. Better yet, just provide a test suite and it will classify the revision automatically.
It's somewhat comparable to incremental programming with a REPL, rather than a compile-link-test cycle. Sure, you only get feedback on your code "slightly faster", but that makes a tremendous difference.
Git is hyped pretty hard (software hipsters seem to be gaga over it, probably in part because of gasp Linus), but if you ignore all that, it is a pretty good version control system.
