[rspec-users] rspec at github

[Wincent Colaiuta]

El 9/4/2008, a las 20:15, "David Chelimsky" <dchelimsky at gmail.com>  
escribió:
>
> It's official: http://tinyurl.com/5npxxb
>
> Git some happiness!
>
> Cheers,
> David


One thing, on the wiki you say:

> The easiest way to create a clean history is to make a new branch  
> that tracks RSpec’s master branch, and then cherry-pick your own  
> commits to it. For example, say you had a commit whose sha is abc123  
> that you’d like to contribute to RSpec. However you made a previous  
> commit to your repo that would be irrelevant, but that would get  
> pulled in when we pull from your repo.

Although it _may_ be the "easiest" way, I think there are better ways  
which should probably be mentioned for any patch series which has more  
than one commit in it (and breaking changes up into logical steps  
certainly makes reviewing changes much easier). So I think you should  
probably also mention the utility of topic branches and using "git  
rebase" to keep them up-to-date eg:

   # make sure we have the latest changes
   git fetch

   # create a new topic branch
   git checkout -b my_topic origin/master

   # hack, hack, hack, committing along the way
   ...

   # make sure we have the latest changes
   git fetch

   # prepare branch for submission
   git rebase --interactive

   # make a patch series for attachment to a lighthouse ticket
   git format-patch

That's the basic idea. There are some shortcuts that can be taken (for  
example, if you are already on your master branch and it is set up to  
track the remote origin -- and it will be if you did a standard "git  
clone" of the RSpec repo -- then you can just do "git checkout -b  
my_topic", preceded by a "git pull" if you want to pull down and merge  
in the latest changes from the remote).

"git rebase --interactive" is a really amazing tool that you just have  
to try out. It allows you to:

1. "rebase" the commits so that they always appear to be "on top" of  
the HEAD of the master branch, instead of several commits back; this  
makes the history cleaner because things look like linear development  
(technically a "fast-forward" merge) rather than a merge - this  
rebasing happens automatically when you run "git rebase"

2. skip commits; for those times when you realize that a change  
doesn't really belong in a particular series

3. "squash" multiple commits into one - perhaps you got a bit commit- 
happy and there are multiple changes that should logically be grouped  
into a single commit

4. edit or amend commits; either just tweaking the commit messages or  
actually changing the contents of the commit (for example, you can  
split a commit into a series of commits, or you can add completely new  
content to a commit)

5. reorder commits: it's amazing how easily this is done (just by  
reordering the commits in a list), and it can allow you to put a  
series into a more logical order that will be more easily reviewed

In short it is an incredibly powerful tool, and you simply must try it  
in order to see how amazingly easy it is to do all this stuff which  
you would never dream of doing with Subversion... Go and try it now,  
really!

And best of all, it leads to better code and a better RSpec, because  
the more reviewable your code is, the higher the quality of the stuff  
that ends up getting integrated.

Cheers,
Wincent