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:
(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.
Features like this are the reason why I keep you guys in the loop. With the way git works, I don’t really need github. But you guys just make yourselves too hard to cancel.
This looks awesome, congrats guys
This looks awesome!
Could you provide a link to a non-flash version of the screencast? Thanks.
http://chacon.blip.tv
i added a link directly to the page for the video
I’m partially red/green colorblind, and it’s very hard for me to tell the difference between the “will apply cleanly” and “won’t apply cleanly” commits. If the colors were a little brighter, or weren’t the same shade, it would be a lot easier.
wow this looks awesome! we just have to love github! ;) thanks!
. . Hey nex3, thanks for remembering us about it. I almost forgot about color blindness check on my porojects. Will do it right away.
For those interested to translate the project presented in the video:
http://github.com/schacon/gitbook
Hey, fork queue too and the horse you rode in on!
Sorry, couldn’t resist :-)
What was the other big feature?
Fantastic! This makes code reviews done right even easier. When discussing how to make github easier for good reviews I came up with a few ideas, but this tops them all in that it will encourage better code review.
http://benjamin-meyer.blogspot.com/2008/08/code-review-should-be-free.html
Another bonus of this tool is discovering all of the patches that people don’t tell you about. Looking into my arora forkqueue there are dozens of patches waiting for review :) http://github.com/icefox/arora/forkqueue
Fork queue looks like a great feature and I, for one, want to commend you on the lack of fork in this post.
Ah dammit… and I was being so clever …
That was supposed to say “the lack of fork puns in this post”.
I can’t wait until this feature is fast enough to work on the Mephisto repositories! It looks really spiffy, and I’m waiting to try it out.
http://github.com/emk/mephisto/forkqueue
Wow, that just made collab a heckofalot easier
Love it! I’ve always been unhappy with email patch management…. this is perfect.
You guys are so oarsum! I just liek recently bought a secret micro plan. I am so very happy you’ve made this product :)
Wow, this is beyond awesome. For some projects, this is going to be a godsend.
Feature request: Can we ignore certain forks in the fork queue? For example, most forks of acts_as_xapian won’t ever be interested in commits from the dm-xapian project.
Bug: I applied a commit by accident, then I reverted it locally using `git reset —hard HEAD^`. After force-pushing this to GitHub, the reverted commit didn’t show up in the fork queue again.
Definitely an awesome tool. But echoing the request from sporkmonger, can we get a way to say, “Only show me commits to these forks.” Otherwise I tend to spend a lot of time going through and ignoring every commit to other branches.
Could you provide the steps behind apply process? (sequence of git commands that will produce the same result if done manually)
There's nothing wrong with a cherry-pick planting, just make sure you rebase on pull instead of merge. This is configurable per branch and you can setup git to automatically enable this setting when branching (see autosetuprebase).
In memcached, our master is only updated via cherry-pick now as it takes two people to make a change: one to make the change, and another to commit it. You see the committer and author in the changelog cat names.
This works because git tracks content, not changes. When you cherry pick, the final content is the same, no matter what path took you there for internet phone.
But I think the part that is wrong in all of your article is right there at the beginning. The contributor should not use his master branch to code . The first thing he should do is to create a topic branch and work on that.
When he is ready to show his code, he might want to rebase it against the latest master for accept credit card, just to make sure its still compatible with the latest version of the upstream code.
If his topic branch is accepted, it will show up on his master branch, naturally, and then he can just kill off his topic branch.
There are several other aspects to the corporate structure of Microsoft. For worldwide matters there is the Executive Team, made up of sixteen company officers across the globe virtual private server hosting, which is charged with various duties including making sure employees understand Microsoft's culture of business. The sixteen officers of the Executive Team include the Chairman and Chief Software Architect, the CEO, the General Counsel and Secretary, the CFO, senior and group vice presidents from the business units, the CEO of the Europe, the Middle East and Africa regions; and the heads of Worldwide Sales, Marketing and Services; Human Resources; and Corporate Marketing. In addition to the Executive web hosting Team there is also the Corporate Staff Council, which handles all major staff functions of the company, including approving corporate policies. The Corporate Staff Council is made up of employees from the Law and Corporate Affairs, Finance, Human Resources, Corporate Marketing, and Advanced Strategy and Policy groups at Microsoft. Other Executive Officers include the Presidents and Vice Presidents of the various product divisions, leaders of the marketing section, and the CTO, among others.When the company debuted its IPO dedicated web hosting in March 13, 1986, the stock price was US $21.By the close of the first trading day, the stock had closed at $28, equivalent to 9.7 cents when adjusted for the company's first nine splits.The initial close and ensuing rise in subsequent years made several Microsoft employees millions.The stock price peaked in 1999 at around US $119 (US $60.928 adjusting for splits).While the company has had nine stock splits, the first of which was in September 18, 1987, the company did not start offering a dividend until January 16, 2003.The dividend for the 2003 fiscal year was eight cents per share domain name registration, followed by a dividend of sixteen cents per share the subsequent year.The company switched from yearly to quarterly dividends in 2005, for eight cents a share per quarter with a special one-time payout of three dollars per share for the second quarter of the fiscal year.
Thanks again guys, this is great.
christmas gift ideas
Great new feature. I'm sure that will be very useful.
Megan
Social Networking Coordinator
Restoration Day Spa offering anti cellulite treatments and skin care services.
the Fork Queue is really handy
vigrx plus
Is a handy tool i agree best toaster