Git, Mercurial, github, bitbucket

[deborah]

I want to spin off a new post from the log of last night's IRC developer meeting. The topic of GitHub came up in the meeting, and some concerns with that idea have been raised in the comments of the previous post. vlion's concerns largely address the difference between mercurial and git, whereas karelia's concerns also address that difference but touch incidentally on the hypothetical benefit of working in the more public environment of Github.

I was talking to allen and he pointed out that there are really two different issues in play here, because we can go to a shared, public, relatively popular, FLOSS-friendly environment without ever leaving mercurial, namely, Bitbucket.

I'd actually say there are three questions:

1. Are there benefits to git over mercurial, and if so, are those benefits enough to outweigh the cost of switching to a new source control system?
2. Would we like to move our source control management to a public, shared, FLOSS-friendly environment? If so, why? Do we think it would be more friendly to our current developers, do we think it would make it easier to bring in new developers, some combination of the two, or something else?
3. If we want to move to a shared environment, do we feel that there is a strong reason that it should be Github? What are those reasons, if so? If we think git is worse than mercurial, but we do think there's a benefit to moving to Github, which reason should prevail?

Actually, we should probably add a fourth question, which is "would any of our needs be better served by using mercurial more in the fashion for which it was intended?"

Keep in mind when I write these questions that I use github for other projects and like it,and I have never used mercurial intensely enough to have strong feelings about it either way. Personally I fell in love with Perforce at an early date and find all other VCS systems to be it pale yet free imitations. But I do think that if we make a switch like this, these are the questions we need to answer.

Comments

[crschmidt]

I know that I'm reiterating some things that others have already said, but I do want to say that although I am personally opposed to Github for a number of reasons (among them the fact that it is a proprietary itself), I do feel strongly that GitHub is a huge win for open source development projects.

Note that I think that Git is a *bad* thing in general for increasing developer involvement: it is full of sharp edges that are confusing at best, and actively harmful at worst. (hg is better in this regard, in my personal experience, but I've used git more, so it has more chances to shoot me in the foot.)

However, Github:
- Hides much of the pain. By having UI-level options for forking, the distributed model is not just encouraged, it's de facto; many people use github effectively without having any idea on how git really works or is meant to work.
- Is the clear winner on 'network effect' -- huge swaths of the open source community already have GitHub accounts, which removes obstacle #1 to contributing development to any code base.

Despite being against Git, and GitHub, I helped a project transition from Subversion to GitHub in September of last year. Since then, we have seen a huge number of new developers participating in the development of the project; the project in question is now reported on Github as having more than 140 'forks' where people have made changes to the code, and that's excluding the hundred more or so pull requests that have been integrated into trunk and are no longer forks.

Git is painful. GitHub hides much of the pain, tries to do outreach to solve the remaining pieces, and makes many parts of interacting with an open source project trivially simple in a way that nothing else does. As good as the other tools may be, I haven't seen any evidence that other tools compete when it comes to the massive success that Github has had in getting open source development opened up to a massively larger number of people.

[mark]

Yeah, I totally agree that git is more painful than hg and other options. For me though, the real wins from git come because it has that power and flexibility. I love and abuse rebase and it's really something amazing that I can't live without anymore, and to my knowledge, hg doesn't come close to giving you that power.

That said, I think that git is ultimately going to disappear underneath management tools that people use and people will hopefully not use git itself. It's a nightmare of usability, so I don't want us to be using git directly much -- git-flow + github is the winning combination for me, not git itself.