If you're getting as many merge conflicts with Git and as you were in Subversion then something is seriously broken with your team's development strategy. Git is built with a much better merge algorithm, such that conflicts should happen less often. Git was built to merge hundreds of lines of kernel code every day, and if it didn't do that quickly and accurately, there would have been no point to the project.
The extra complexity you speak of is negated by the fact that you don't have to use the "confusing" features if you don't want to! This is the number one thing that upsets me when people give Git a hard time.
99% of the time I come across someone that says Git sucks is because they ran a command like 'git-filter-branch' when they were trying to do something clever and it wiped out their data.
I don't Git should have to apologize for giving more power to developers as long as they're comfortable using it.
I've taken the time to explain my opinions, and they're fairly well-informed: I use Git daily, for real work, and I used Subversion for many years. Moreover, my opinion is fairly measured: I can see the value of Git -- just not for most types of non-distributed development. My direct experience with the system trumps whatever theories you have about the quality of the approach.
Maybe my experience is due to the way that I use version control; maybe I'm just not a "power" user. I don't know. All I really know is that if you can't a handle a civil discussion of a version control system without resorting to emotional retorts, then you're WAY too invested in the debate.
I branch at least several times a day when working on a project in git, and often throw them away quite soon afterward.
Why does every defense of Git seem to begin with a personal attack on the intelligence and knowledge of the critic? Trust me -- I understand the value of branches. I branch frequently in Subversion, and have never had problems (however "heavy" the branches may have been).
The primary feature of Git is distributed development, not branching.
Because nearly every argument I've heard against Git has been stupid or just plain wrong. It isn't necessarily true that a person making a stupid argument is stupid, but it seems to be true more often than not.
I am usually aim for something a bit more civil than "you're stupid", but I've certainly thought that very loudly when reading criticisms of Git. I gave a Git talk at a local user group meeting recently. One audience member was deeply upset about "git reset" and how Git should never be used because of that feature. I thought to myself, "I guess you never use the backspace key either." (And of course said, you can easily delete commits with Subversion. svnadmin dump, edit the dump in your text editor, svnadmin load. I have done this to correct bad merges in the past -- deleting commits is much easier than living with a dumb mistake for the rest of my life.)
Anyway, I think my point is that a lot of people are afraid of anything new, and they come up with dumb arguments to convince themselves that the new thing is bad. Git is very new, and version control is a touchy subject, so a lot of bad (and ignorant) arguments come up. It is really sad, actually. When I discover a new way of thinking that makes my life easier, I don't get upset. My life has become more enjoyable... why would I not want that!?
When you find yourself thinking this, it's a good sign that you need to take a step back, take a deep breath, and think a little harder about your opponent's arguments.
Branches (in the sense of SVN, p4, etc) are a subset of the functionality that distributed development entails (local history, cheap copy operations, fast merge, etc). You can get a ton of mileage out of git, hg, etc without any distributed collaborators.
The point remains, branching in SVN is much more expensive. There's no comparison.
Apparently a lot of Git users haven't heard, but you can branch in Subversion, too. That's why "svn merge" exists -- it's a core feature! Yes, you have to remember the branch point and change directories to do it (and I grant that this is slightly annoying), but in my experience, the results are equivalent. You still have to resolve conflicts at about the same rate as with any other revision-control system. And the annoyance that Git saves you (by remembering the branch point and saving a 'cd'), is more than offset by the extra complexity of multiple masters, obtuse commands, non-local branches, and the oddball, multi-stage commit process.
To me, the extra complexity of Git is only justified when you're working on a project that has multiple, far-flung contributors who frequently work offline. Otherwise, to extend the author's metaphor, using Git is a lot like having a good set of work pants -- but wet, with sand in the crotch.