DevOps Zone is brought to you in partnership with:

John Esposito edits Refcardz at DZone, while writing a dissertation on ancient Greek philosophy and raising two cats. In a previous life he was a database developer and network administrator. John is a DZone Zone Leader and has posted 331 posts at DZone. You can read more from them at their website. View Full User Profile

Poll: Has Git won the version control wars?

10.31.2011
| 17181 views |
  • submit to reddit

Your clicks tell us that Git is gittin' popular here at DZone.

Grab our FREE Git Cheat Sheet!

Get FREE PDF

Okay, the learning curve is a bit steep -- Think Like (a) Git led our link charts lately, and our Git Refcard has received over 30,000 downloads in a little over a year.  The good people at Stackoverflow observed that, although questions about Git have exploded lately, that might not mean that Git is actually getting more popular -- just that Git users need a lot of help.

So we're curious to see what VCS you DZoners are using.

Now, today we're wondering specifically about Git. But depending on poll results and discussion, we're already looking forward to a follow-up poll asking 'which VCS would you LIKE to be using', in case Git turns out to be awesomest but hardest (as some people think).

So, developers:

Do you mainly use Git? or something else?

Comments

Andrew Thorburn replied on Mon, 2011/10/31 - 11:46pm

I think that Git has probably 'won' the version control wars as far as open source goes. It's not like SVN or CVS are going to entirely disappear anytime soon (though I'm sure lots of people wish they would), and Mercurial and Bazaar have loyal, if slightly smaller, bases of users.

I imagine GitHub has quite a lot to do with that - if I heard about a Mercurial or Bazaar version of GitHub as often as I hear about GitHub itself, then perhaps one of them would be coming in first.

As always, it's a different story in corporate land, where some of the advantages of Git aren't as obvious. e.g. I don't travel, or work offline, much at all, so being able to work completely offline with Git isn't really relevant to me (I'm not saying this is the only advantage Git has! Just that's it one that isn't relevant to me).

And of course sometimes they do have requirements that Git isn't compatible with. I recall a poster elsewhere on DZone (or an article linked from DZone, maybe) said that Git wouldn't be great choice for them as they do game development, and typically need to store large amounts of binary data in version control, which Git isn't designed for, whereas I think it was Perforce (or ClearCase something?) was much better at that, so that's what they used.

Me personally? I use SVN at work, but if I was doing OSS stuff I'd be using Git.

(Aside: how can I make DZone automatically insert line breaks? Having to manually insert br tags tiresome)

Mason Mann replied on Tue, 2011/11/01 - 4:10am

In the corporate world, svn is still huge because 1) it's simpler and 2) it works well with largish binaries. I hope git will take over the world, but it won't happen anytime soon.

Fabrizio Giudici replied on Tue, 2011/11/01 - 4:47am

 

 

I think that Git is the most popular among DSCMs, but I am definitely a Mercurial guy. The two systems today can do the very same things (including branching, even though there are still a lot of people who believe that in order to branch with Mercurial you have to create a separate working area), but Mercurial is much, much simpler to understand.

CVS and SVN are still very popular in the corporates. CVS is a real problem and I always push my customers to leave it and pick SVN, at least. A DSCM can be overkill for most corporates, as Andrew said, and the complexity wouldn't pay for the advantages. So, harbouring at SVN is fine.

Still, there would be definitely some advantages for a corporate to use a DSCM, even though there's no people working offline. One for all, the release process with Maven is definitely smoother with a DSCM, as thanks to the separation between commit and push you can easily set up a workflow where you have a transactional release (I mean, either everything is fine, or the release fails with no consequences).

Otengi Miloskov replied on Tue, 2011/11/01 - 9:25am in response to: Fabrizio Giudici

+1 Mercurial here too. Git is great but I like more Mercurial, I used a lot subversion before but when I discovered Mercurial I never looked back. Yes is better those corporate's use subversion than something more ancient. But if someone ask me I will say Mercurial or Git is the way to go.

John J. Franey replied on Tue, 2011/11/01 - 1:12pm

Here is FelipeC who goes to the mat defending his position that git is better than mercurial. I found this page looking for an answer to this question: "If git and mercurial are apples-to-apples comparable, how is it one is simpler to understand than the other?"

FelipeC's answer, I think, is that 1) git and mercurial are not exactly apples-to-apples, but very close, and 2) the front end differences, such as documentation, tooling and command syntax, are transient distinctions that have largely fallen away. But the main point of the blog, which rankles the hg users, is that git has a superior branch model.

A few commenting readers have responded to his challenge of providing a use-case that is simpler in hg than git but have given up leaving behind ad hominen attacks along with some yelling and foot-stomping. I think the hg user's side of the discussion needs help raising the quality of their argument. (its still a live discussion even though the original post is jan 2011).

Mikael Couzic replied on Tue, 2011/11/01 - 2:48pm

One of the reasons I use Mercurial over Git is TortoiseHg. Last time I checked, there was no equivalent for Git, but maybe it has changed since...

Cristian Vasile... replied on Tue, 2011/11/01 - 3:15pm

One thing that I think it's extremely important is the ability to merge branches. SVN failes big time if you changed the directory structure. Git is probably better at guessing the renames.

But why should it guess? I like Bazaar a lot because it versions file and directory renames instead of trying to guess them from a copy+delete.

Jilles Van Gurp replied on Tue, 2011/11/01 - 3:36pm

I think one should be careful to declare winners in any IT related wars. People are still bashing each others heads in over vi vs emacs or kde vs. gnome.

On the other hand, git usage is clearly growing more rapidly currently than most of its competitors. And for good reason: it is that good. That doesn't mean it is perfect but it does mean that it should be your first choice if you are looking for a new versioning system. If you are not, just stick with what you have, for now. 

Migrating source code to another version control system is a headache that few people will want to deal with on bigger projects. You have to worry about all sorts of things like making sure CI builds continue to work; deployment mechanisms don't suffer; getting people to do the right things; etc. There's a big if it aint broke don't fix it kind of argument here. But ironically this is also why git is so popular. Being the #1 choice for OSS developers means that tooling is rapidly catching up to similar levels people have come to expect from e.g. subversion. Additionally, git integration with subversion is pretty good as well. I routinely use git as a client for subversion repositories (all of the advantages of git, almost none of the downsides of svn). And finally, svn to git migration is a well explored path by now. You should have few, if any, obsctacles.

Git offers a large enough improvement over svn that it is generally worth the trouble unless you don't really care about version management to begin with and are perfectly happy to routinely access 3x times the amount of diskspace on your slow laptop drive using svn where git would use much less than that for a work copy + full history. Also, next time you find yourself picking apart a botched merge or tedious commit conflict be very aware that git probably would have made that problem vastly less complicated. Once that occurs to you a couple of times, read up on git svn (or whatever the cvs equivalent is, if you are so unlucky to be still stuck with that). Basically, I did and never looked back.

There's a fine line between conservatism and idiocy. A lot of idiots waste a lot of time pretending to be conservative. I know of multiple projects that depend on managing subversion branches and merges that waste endless amounts of time on stuff that git was designed from the ground up to handle effortlessly. That's just stupid.

 

Jilles Van Gurp replied on Tue, 2011/11/01 - 3:39pm in response to: Mikael Couzic

http://code.google.com/p/tortoisegit/

Here you are. Alive and kicking apparently but haven't had a need for it personally. Also great eclipse support in the form of egit.

Dirk Estievenart replied on Wed, 2011/11/02 - 5:18am

I use git whenever I can. Admitted, the learning curve was high coming from SVN, but it was definitely worth the effort. I even use git at work to create a "buffer" between me and the official, proprietary version system, mainly because it's much too slow. It's also much easier to take my work home: just clone the project on a memory stick. I also worked a little with bzr and Hg, and enjoyed them too. The point IMHO is that people really should start using distributed version systems.

Matthew McCullough replied on Wed, 2011/11/02 - 10:37am

I have really enjoyed using and learning Git these past four years. GitHub has made my outbound contributions and request for contributions from others on my OSS and commercial projects significantly smoother than any past solutions.

I understand and respect the "Git is hard" argument from devs coming from a centralized version control system like I did. However, I think many things that are hard are worth it. Only exploration confirms or rejects this. Refactoring a thought from Rich Hickey at Strange Loop, "just because brain surgery is hard doesn't mean everyone should avoid learning it."

I'm doing my part to help others absorb these new ideas. I'm producing and pointing to many free resources to help folks learn Git whenever I can.

Matthew's Git Links
ProGit Free eBook
GitHub's Git Help Pages

In sum, no matter your feeling for Git, please help others have a deeply informed opinion of these new DVCS systems. Even if they don't adopt the tool, they will have a greater knowledge of some unique ways to solve computer science, historical data, and object versioning challenges, perhaps repurposing these tactics for their own programs.

Mitch Pronschinske replied on Wed, 2011/11/02 - 12:57pm in response to: Matthew McCullough

@Matthew

Also, you wrote Git Refcard.  I'd say it was a pretty kick-ass free resource with 30k+ downloads  :)

Harald Wellmann replied on Sat, 2011/11/05 - 3:30pm

I just don't understand all the hype about Git.

There is a fundamental difference between distributed and centralized VCSs. Once you've understood the basic concepts of either family, you can compare different representatives of each family.

Lightweight branches and a push and pull model are a significant advantage of DVCSs over centralized VCSs, especially useful for open source projects with a large developer and user base.

So if you think a DVCS is the way to go, the basic quesion is, Git or Mercurial?

I've worked with both, they both do the job, but I still think Git is overly complex and counterintuitive. Mercurial beats Git by far in terms of usability. The same holds for the Eclipse integrations (MercurialEclipse vs. EGit).

When I was new to Git, it took me some time to figure out that a "pull request" is not a Git concept at all, but only a feature offered by GitHub. GitHub has some of the sex appeal that Git is totally lacking. It's a pity they didn't build MercurialHub...

So I really think much of the popularity of Git is actually due to GitHub.

If you're happy with Git, then that's fine. If you're a DVCS beginner or a Git user feeling challenged by the multitude of commands and options, I'd definitely recommend Mercurial as the more user-friendly alternative.

 

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.