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

[mark]

You can emulate this behavior with MQ, sure. I don't want to, though. I dislike MQ. hg is okay, but I prefer git for many reasons.

(reposted as my staff account, because I was in the wrong window)

[pauamma]

OK, mq is a standard part of hg AFAIK, so let's turn your argument around: I'm going to declare some parts of git offlimits because I don't like them, then compare whatever's left to the whole of hg (including mg). Does that sound like a fair, objective comparison? If your answer is "no", as it reasonably would be, I submit your comparison isn't fair or objective either.

[kareila]

MQ is sort of a different beast, actually, because it sits on top of the repository and manages applied patches. From the repository's perspective, it's completely separate from the commit history. IIRC, it started life as sort of an ugly hack and was later folded into the standard distribution when it became popular (well, to the extent that Mercurial is popular). Kind of like how QuickTime started out as a little video platform and eventually got baked into the core Mac OS.

I think what Mark is trying to say here is that he wants us to move toward a workflow where instead of having to generate a patch and upload it to Bugzilla (which MQ is very helpful with), he wants us to be able to commit changes on our own branches and request to have them pulled into the main trunk, no patches needed. There are advantages to be gained from that approach but also tradeoffs to be made.

[mark]

Thank you! Yes, this is what I was aiming for, and said very badly. :) Sorry, Pau!