The Fork Queue

I would like to introduce you to the Fork Queue, the first of two big features that rolled out today. As of a few minutes ago, everybody should now have a ‘Fork Queue’ tab on each of their projects.

When you click on that, you’ll see something like this:

This is a list of all the commits that exist in your projects fork network. If a couple of people have forked your project and then committed to their fork, you will now see a list of each of those commits, grouped by user, under this tab.

What’s more, you can click on a checkbox next to each one and then choose ‘Apply’ from the dropdown menu to cherry-pick those commits onto one of your branches. You can even create a new branch to apply them to for testing. Just click ‘change it’ next to your listed integration branch:

When you choose a few commits and then choose ‘Apply’, it will take each one and cherry-pick them onto whichever branch you designate as your integration branch, one after the other.

When it is done, it will tell you which of the cherry-picks applied cleanly and which failed. You can abort the process at this point, or you can move your branch forward to it’s new head with all those patches pulled in.

You can also ignore commits that don’t apply or you don’t want, so you don’t have to keep considering them.

This tool allows you to do a lot of repository collaboration maintenance entirely from the website. You can setup an integration branch that you ask everyone to make sure their commits apply cleanly to and pull them in one by one, entirely online. It also gives you great visibility to what is out there in your forked network and what you have or have not brought in yet.

For a bit more information, and a demonstration, check out our screencast on it:

https://blip.tv/play/AeD_CYzxOg
(if you want to download the movie, you can get it from http://blip.tv/file/1580699)

We hope this makes some of your project maintenance tasks much easier. We’re planning a lot more for this new feature – if you have any ideas as to how we could make it even better, let us know.

Update: Commits you have rebased in will continue to show up, so just ignore them to make them go away. Also, for projects that have had a ton of forks with pushes, it may be too slow to use right now – we’re working on that. There shouldn’t be too many of those, though.

Update 2: Just to be clear – the suggested workflow for this would be to use the tool to pull in patches from forks into a testing branch and ignore the ones that aren’t ready or don’t apply. Then you would want to fetch that branch down and test the code before merging or rebasing it into your master branch. This allows you to do a email patch style workflow without actually having to deal with patches over email or having to add a remote to your local repo every time someone submits something.

Update 3: There is a bug we’re working on where the fork queue might show you the wrong commit for your master branch. Before you use this, double check that the master head is pointed where you think it is, or you might have some resetting work to do. It shouldn’t happen to many people (it’s if you pushed your remotes to us via ‘–mirror’ or something), but we’ll have it fixed soon.

Written by

Scott Chacon

@schacon