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

[pauamma]

Ewww. Perforce. :-)

Other than that, what are you and allen doing in my brain? :-) (Time of the first meeting made it impossible for me to attend, but I definitely intend to revisit those questions at the 2nd meeting.)

[exor674]

I think part of the problem is that mercurial's branching/merging is inferior, so we'd still have to so weird things.

[pauamma]

I think part of the problem is that there's no visible, objective set of requirements (what we need or want of a VCS, and why we need or want that) that we can judge statements like "mercurial's branching/merging is inferior" against. Is there such a document that you and or Mark can pass around so we can go over it at the next meeting?

[kareila]

Cosigned.

[deborah]

yeah, after I made the post I was thinking about it some more and I realized the problem is that we have been going about this in a tool-centric view, not a problem/solution-centric view.

What are our problems, what are our goals?

Then, what tools would serve those needs?

(I have no problem with saying that the features of the available tools should be helping to drive our problem statements. 10 years ago I never would have said "public repository that makes it really easy to share code with other people in open source" is a feature, because while there was sourceForge, sourceForge never made any of that easy.)

[fu]

I made an attempt to address the problems/goals bit in the assumptions / summary part of the run through of git/mercurial workflows. Is there anything else useful that can be added? I'm not very good at organizing outlines, but I can do specific questions!