
Delightfully Wrong About Git - Anon84
http://www.unethicalblogger.com/posts/2008/11/delightfully_wrong_about_git
======
timr
Reading these git "success" stories, I find myself asking the same question
again and again: how many man-months of effort were spent writing "scripts,
hooks and documentation" to transition to a version control system that is
only incrementally better than the one that was there before?

~~~
Locke
In my case the effort was minimal. I certainly wouldn't measure the effort in
"man-months". Here's how it went for me:

0\. Research. This is one small part of why I read HN, and other assorted
"news" sites. I like to stay current with the tools I use. I don't jump at
every new tool just because it's new, but I understand that my current set of
tools is not perfect. Sooner or later, I'm going to replace every tool in my
toolbox with an even better tool. I may like my current set of tools _today_ ,
but I understand that it's important not to get so attached to them that I
stagnate as a developer. I think it's critically important for good developers
to stay "intellectually curious".

1\. I decided that git was worth trying. So, I started using it with my next
new project. This allowed me to establish a new work flow without interrupting
active projects. Yes, you'll need to read man pages, cheat sheets, etc.
There's no point to adopting a new tool if it behaves exactly like the old
one. So, it shouldn't be a surprise when you actually have to commit to
_learning_ the new tool. That said, I found git to be more user friendly than
I'd expected based on the negative comments I'd read online.

2\. I decided I liked the new work flow and that git was worth switching to. I
moved my old projects over to git in less than a day and used git for all my
work moving forward.

I'm sure this transition is different for everyone. I'm also sure that git is
not yet (and may never be) a good fit for some people. But, I really don't see
the point in disparaging those who think the switch _is_ worthwhile for
_them_.

~~~
timr
I don't think I'm "disparaging" people who make the switch. If you want to use
git (or mercurial or darcs or whatever), that's your choice; there are
situations where it makes sense. But in most cases, I question the technical
judgment. I use Git myself right now, and don't find that its benefits
outweigh its costs for non-distributed projects.

I think that Linus Torvalds scratched a very personal itch with git, but that
it needs a _lot_ of time and polish to be a valid, general-purpose competitor
to subversion. Couple that with the fact that I've seen very few rational
discussions of the _benefits_ of the environment, and lots of references to
the _hype_ , and I've become quite skeptical.

~~~
spc476
The major benefits to me is that git is fast, branching is cheap (and yes,
cheap branching does change how you approach a project; I never did figure out
branching under cvs and apparently, it's just as easy under svn as it is under
cvs) and the merging is incredible (I'm using it to maintain two versions of a
PHP project, one for MySQL and one for PostgreSQL:
<http://boston.conman.org/2008/08/07.1> )

Granted, if you are used to a centralized workflow, then I can see where git
might be different enough to cause some strain. But even on a one-person
project (and I have plenty of those), I found git much easier to use than cvs
(or svn for that matter) even though it took some time to get used to the
decentralized nature of git.

~~~
silentbicycle
Why should you need to "get used to the decentralized nature of git" on a one-
person project, though?

~~~
spc476
I was still in a "centralized frame of mind" when I started using git. I do
development on one machine, but deployments go to the server, and for the
occasional oversight, bug fixes that happen on the server need to be pushed
back to the development machine. git didn't work quite the same as cvs in that
reguard, and thus, I had to change my workflow just a bit.

------
theBobMcCormick
Why all the love for Git, but nobody every talks about Bazaar, Mercurial,
Darcs, etc? Sure Git is faster, but unless you've got a enormous code base
(like the linux kernel), it seems like Bazaar or Mercurial would be a better
choice than Git.

~~~
schacon
I started using Git as a filesystem long before I started using it as an SCM,
so I never really went through the 'choosing' process, however, from the
people that I talk to about this, Gits popularity tends to be because of the
cheap local branching. There is no other system out there that is nearly as
good at this as Git. Baz, Merc, Darcs, SVN, Perforce, CVS - these are all
patch or changeset based systems where branching is tacked on in a complicated
manner. Even the Hg Book recommends cloning for real branches over the local
branch system it has.

This functionality is truly a deal-breaker for most people, and completely
changes the way you develop and think about development. There are very few
people I've ever met that have learned the git branching system (which is not
hard to learn) and then went back to another DSCM. The fact is that none of
these other systems are nearly as good at this as Git is because they way they
think about history (patches/changesets vs DAG snapshots) is simply not well
suited for it.

That, plus the fact that Git usability has improved so much recently that it's
hard to argue that any of them are really easier to learn, and super powerful
features for more advanced users like the staging area (which I also would
hate to live without) I think explain why Git is becoming more popular at such
a fast rate.

It's not that the other systems aren't getting love, but that it's getting
harder to argue against Git and while all of them share largely the same basic
data storage mechanism, Git's is entirely different, so while Git can always
make the UI better (and it constantly is), the other systems are having a
really hard time trying to catch up with the features Git had from day one.

Others may disagree with me, and will normally argue that it's just a fanboy
bandwagon koolaid whatever, but I think that the real reason is that when most
people learn Git fundamentals they realize that they become more efficient and
none of the other systems can do that for them in the same way.

~~~
tekkub
Branching was by and far the winning feature for me. SVN made branching and
tagging very time consuming (making a full copy, to the server nonetheless).
Merging correctly on SVN? Never the first time! Usually took 2-3 tries before
you got the syntax correct. Dry-run never really helped either. SVN merging
was leagues harder to learn then the entirety of git for me.

The simplicity of making a local directory versioned is wonderful too. It has
use far beyond code. I can quickly version my documents folder, easily recover
from mistakes, and with one little push I have a backup! To even try to do
this in SVN was another headache, and it required an SVN server somewhere...
with git I don't have to push if I don't want to.

