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?
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.
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.
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.
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.
I'd say from experience that significantly less effort is spent transitioning to git than is spent worrying about and complaining about git before actually trying out the switch.
It took me a few hours to learn enough in git to replicate my experience in svn; sure, it takes longer than that to learn some of the other features, but the only time that is actually lost is the time spent relearning what one already knows.
If you're just replicating Subversion, why use Git at all?
(I'm not being flippant -- I hear this from people all the time, and it really makes no sense to me. If you're just going to set up a single central repository, why wouldn't you use the proven, capable tool for that workflow? Git is rather poorly documented, and works with only a tiny fraction of the professional tools that support SVN.)
I didn't say I was only replicating--I said that it took me a few hours to be able to replicate SVN. The reason you switch isn't to replicate SVN, its to take advantage of the other features available, like local commits (see http://news.ycombinator.com/item?id=374413 ).
My point is that the only time you lose is the time you spend relearning what you can already do with SVN: all time spent learning new things isn't lost time at all.
It seems to me that Git's ecosystem is rather more developed than Subversion's, despite its younger age. I haven't seen any hosting service for Subversion repositories that approaches GitHub (and even `gitweb` is pretty nice actually) and the amount of stuff in e.g. http://git.or.cz/gitwiki/InterfacesFrontendsAndTools is pretty huge compared to what I've seen for SVN.
When it comes to documentation, not only is the reference manual excellent in the usual way of Unix reference manuals, but I also know of six tutorial Git books, several of which are free online: the Git User's Manual, the Git Community Book, Git Magic, Pragmatic Version Control Using Git, Pro Git, and Git Internals.
As I said in another comment (now deleted), I'm using Subversion on a project for the first time in years, and I constantly find myself wishing the project was using Git.
I use Git, and am familiar with its benefits and drawbacks, and I don't see more than incremental value for 95% of source control users. It is inherently complex and arcane, and the primary benefit from adding all that complexity (distributed version control) is simply not that useful for most situations.
I think if you're going to make a comment like this, you have to defend the decision to use the new system. Simply pointing to the "fuss" is not enough, when you're rebutting an argument that the fuss is unjustified.
I would say amending commits, creating (and easily merging) topic branches, making offline commits, tracking remote branches (on different repositories, even), and cherry picking commits are more than incremental improvements - they completely change your workflow for the better.
And I'm not sure where you 95% figure comes from, but I see thousands of people using the above features daily. The number keeps growing, too.
As for my rebuttal, the parent was stating as fact that Git was only incrementally better than, say, Subversion. I was merely pointing out that this statement was opinion - not trying to prove it wrong.
In my experience, Mercurial delivers the advantages of git without being "inherently complex and arcane". I would recommend it over e.g. SVN because it has far the flexibility of DVCS features available (and its extension system), but in the case of one user, it behaves very similarly to SVN.
Rather than replying to one of your several other posts, I'll just ask here - what do you think is so "complex and arcane" about git that makes it so difficult to learn?
Speaking as someone who had very little experience with SCMs before git, I have never found myself particularly stuck or frustrated, and have really found it quite easy to learn. There are plenty of great resources online and I've found the man pages detailed enough for quick-reference type stuff. I taught my co-worker how to use git in about 15 minutes, and in another 10 we both understood branches and conflict resolution.
Amen brother! I've been struggling with git for a couple months now, and I really don't see much benefit above and beyond svn. I got so pissed off the other day I took a moment to rant about it: http://blog.aisleten.com/2008/11/23/git-the-fsck-out/
I'm always willing to learn new things, but I heavily disagree with anyone who thinks git radically changes the programming landscape.
I've found git pretty frustrating to learn too. darcs is a lot easier. Still, it sure is more powerful than SVN, and once you know what you're doing (and maybe have a cheat-sheet handy) it isn't much harder to use.
And when they do finally get it working, very nearly everything they praise is also true of other DVCSs. Mercurial, in particular, is already quite well documented and significantly easier to use, with very little loss in features (look at the extensions).
Git has the buzz, though, and many people fail to notice anything else.
40 days later: The git interface sucks far less now than it did when I tried it the first time (before switching from monotone to mercurial), and digging into the new hg "bookmarks" feature made it clear why hg will probably never fully support git-style branches. FWIW.
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.
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.
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.
Using lots of small, short-lived branches conditions you to think about your development in a new way: instead of a single, linear development process, you have a number of parallel development efforts, and you know that only some of them will be successful.
By taking full advantage of fast branch and merge operations, you train yourself to experiment with many possible implementations of the same idea, without completely losing the history of your trials.
