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]

With GitHub, you don't have to make patches anymore. The process morphs to look something like this:

1) You make your changes in your local repo on your hack or whatever environment you use. You use a separate branch for each bug/feature you're working on.

2) When you're ready to submit, you push your changes up to your forked repository on GitHub. This is done with git push with some arguments and is really easy.

3) On GitHub's web site, you submit a pull request to the main Dreamwidth repository.

4) Admins can then review your pull request and request changes and/or merge it in to the base repo.

5) You close out your branches. Or keep them open if you want to do more work on this feature/bug -- you can submit another pull request later!

For more information on pull requests, and why they're so awesome:

http://help.github.com/send-pull-requests/

They really are amazing. You can upload code, discuss it, upload more code, preview things, bounce it back and forth, and eventually merge it in when it's ready to go. It's brilliant.

I wrote up a thing on how to use git flow with GitHub here:

http://qq.is/article/git-flow-on-github

It's pretty easy. There is no "create a patch" and upload files. You make your changes in a branch, commit them, and create a pull request. It's pretty easy.

[pauamma]

How can a reviewer (who may or may not be an admin, whatever that means for a git or github repo) know which uploaded patches are waiting for review pull requests have been submitted but not yet merged?

[mark]

By going to www.github.com and seeing the tab that says "pull requests". You click on it, then it gives you a list.

Edit: GitHub even emails you when one is submitted, so you don't have to remember to go check if you want. :)

[fu]

Hmm, I wonder if that works if you're not an admin on the repo. *goes look to see if there's a setting*

It looks like it only works if the repository is "yours", so if we want to invite reviewers we'll either need to include them in that number, or else maybe add a hook or something to post to bugzilla if applicable.

[mark]

You can see pull requests on any repository.

https://github.com/jordansissel/fpm/pulls

[pauamma]

But can you comment on them?

[fu]

Yup, anyone with a github account can comment.

[mark]

BUNNEHED BY FU. (many hours ago, because I didn't read first)... fail-Mark.

[pauamma]

"Little bunneh Fu-Fu"?