
Why we chose Git, a rebuttal - soundsop
http://www.unethicalblogger.com/posts/2008/11/why_we_chose_git_a_rebuttal
======
cosmo7
I'm not sure emphasizing how much easier branching is in Git is a good idea.
Git already has a "herding cats" kind of reputation.

Programmers like branching because it lets them be less conservative in their
planning. Project managers hate branching for exactly the same reason; only
one branch is going to be the actual product and the other branches are wasted
effort.

~~~
timr
I don't agree with you that branches are unimportant, but I do agree that the
emphasis on branching was a bit of a red herring.

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.

~~~
pjhyett
The amount of FUD you've expelled about Git the last few days is suggesting to
me that you got burned by it at some point. That sucks, but some of the stuff
you've been saying is just flat-out wrong.

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.

~~~
timr
Oh, please...a guy expresses a critical opinion of your favorite version
system, and he's automatically irrational and wrong? Are we debating religion
or technology?

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.

------
DenisM
Wow, GIT fanboys are almost as smug and condescending as Apple fanboys. I wish
I could un-read this post.

------
cooldude127
Sounds exactly like how I would answer the same question. Very rational.

