[collyw]

"Git

First of all, use git for version control. It is modern, works great and the majority of developers are either comfortable in using it or want to start using it.

Its a pain in the arse to learn, overcomplicated for 90% of the cases it is used in. How many people actually need a distributed version control."

(I use Git. It is powerful and useful, but the justification for using it in the article isn't really great. No mention of Mercurial or other version control systems).

[jammycakes]

The fact of the matter is that love it or hate it, Git is now the most widely used VCS on the market in corporate settings (see e.g. http://www.itjobswatch.co.uk/). More importantly though, it is also the de facto standard for version control -- the lingua franca of source code management, communication and collaboration. Subversion and TFS still have significant market share, but everything else has pretty much fallen off a cliff in the past couple of years.

Also, many of Git's most powerful features have nothing to do with being distributed. Easy branching and merging, private versioning, bisect, rewritable changesets, stash, and the ability to cherry-pick individual changes within a file to commit, back out or stash could all theoretically be built into a centralised system.

[Expez]

The benefit of standardizing on a tool that is "good enough" is worth it imo. Learning git is easier than learning svn, darcs, hg, perforce and git and juggling between them when you want to submit patches to open source projects or get new clients.

[collyw]

I am not going to argue with you on that point, because that is the reason I am using GIT. CVS would be far more suited to my personal use cases.

[eropple]

I'm curious how CVS is suited enough to anyone's use cases to be worth discussing when SVN exists.

[couchand]

Don't forget bzr!

[cwyers]

Why not?

[couchand]

The world's inconsistent internet connections are a great reason to require distributed version control. I'm often trying to work from a location without a reliable connection to the internet, be it a plane, train or bus, a coffee shop with spotty internet or a meetup. Requiring a connection to a server kills productivity in those situations.

Perhaps there is something to be said for Mercurial, but unless you were previously on Subversion it's certainly not that it's easy to learn.

[collyw]

Yes, but I would guess that non distributed would suit 90% of use cases. I imagine most software is still developed in one physical location.

[eropple]

Your imagination ignores days where you WFH (like I am right now), it ignores remote workers, it ignores work while traveling, it ignores outsourcing, it ignores open source development.

But who cares, because Git or Mercurial can be used in a centralized manner if you want. But it doesn't have to be. That's why it's good.

[gnaritas]

He's not ignoring anything; he said non-distributed would handle 90% of use cases and that's probably somewhat true. Saying hey I'm one of those 10% isn't a rebuttal to what he said.

[eropple]

I definitely want to see some substantiation that everything I just enumerated is less than 10% of software development, by whatever metrics he wants: number of projects, lines of code, whatever.

[gnaritas]

Those things don't require distributed source control; they simply require remote access. Substantiation simply isn't necessary, you haven't given scenarios that demand distribution and you can't, because honestly there aren't any. Distributed source control is a preference, a style, not a necessity. Central repositories with remote access handle all of those use cases. Other than perhaps the Linux kernel, there's very little software that can't be written just fine with remote works and centralized repositories.

[jiggy2011]

It's easier to find other people who know git that who know mercurial.