Posted by David May 03, 2008 @ 05:28 PM
Michael has written up a guide on how to create and test patches with Git. A good read for anyone interested in contributing or following the development of Rails.
Ruby on Rails was created by David Heinemeier Hansson, a partner at 37signals,
then extended and improved by a core team of committers and hundreds of open-source contributors.
Rails is released under the MIT license. Ruby under the Ruby License.
"Rails", "Ruby on Rails", and the Rails logo are trademarks of David Heinemeier Hansson. All rights reserved.
|
Sponsored by |
 |
Total Git newbie here, but I thought one of the benefits of a distributed version control system for open source projects is that it reduces the need for throwing patch files around. As part of learning more about this stuff, I’d be interested to know the motivation behind sticking with patch files for contributions rather than some clever Gitty forky thing.
Git allows for many different workflows. It makes working with patches really quite easy.
You can also just pull from someone else’s fork quite easily. That’s often nicer (if for no other reason because you can maintain proper change identity), but requires a bit more setup than clone, commit (a few times) and then git format-patch | git send-email
Don’t see how to edit/comment on that page directly, so I will here – the example
should say
Hi Chris,
You will certainly fork RoR repository and develop your features/bug fixes there. But when the time to provide your code to the RoR team comes, you’ll have to provide a patch (easily created with git format-patch), unless you have commit access.
Gerardo, I think you’re confusing “fork” and “clone”. You don’t need to fork (i.e. publish your own copy on github) to develop your changes. All you need is a clone.
Of course, if you don’t have a fork published somewhere, you will have to send a patch, that’s obviously the only way…
But, the original question was: why doesn’t the RoR team prefer to pull changes in using git’s clever distributed features rather than sticking with patch files? (As one team member wrote on the rails lighthouse: “it’s a hassle”, so I’m curious to understand why.)
I assume git patch files still have the same tendency to go stale, no?
This post from RedHat today is relevant and provides some good tips for the patch process using Git:
http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/
Best SCM ever.
Hi Andrew,
not at all. A git clone is a fork.
You’re probably referring to the distinction made by github. But that’s github specific, not applicable to git in general.
@Chris: You can definitely avoid shipping patches around by sharing git branches. However for a single change that’s actually quite a bit more work than this workflow with patches.
For the more comprehensive stuff (Doc Rails and Ezra’s Rack work) we work with branches.
Hopefully we’ll figure out where the balance should lie in the not too distant future. :)
Yeah, Git allows for many different workflows. It makes working with patches really quite easy.
I will learn Ruby. PHP Suxx :-(