Rspec at github

It’s official: http://tinyurl.com/5npxxb

Git some happiness!

Cheers,
David

I see your tinyurl and raise you a rubyurl:

http://rubyurl.com/xAod

“Using git submodules to track vendor/rails” in which the author uses
rspec (despite the title) in his well-written exposition on using
submodules to track external dependencies.

In the comments for that post you’ll see François Beausoleil is
updating Piston to work with SVN and git. I’ve had no luck getting a
recent Piston beta to track a SVN repo (rspec/_on_rails) in the
context of a git repo, but YMMV.

/g

On Wed, Apr 9, 2008 at 1:43 PM, David C. [email protected]
wrote:

George A.

BenevolentCode LLC
O: (410) 461-7553
C: (410) 218-5185

[email protected]

On Wed, Apr 9, 2008 at 2:43 PM, David C. [email protected]
wrote:

It’s official: http://tinyurl.com/5npxxb

Git some happiness!

Yay!, good news!

BTW, there is a doc or something to help you get the correct
environment to spec RSpec? I saw your pre-commit stuff, but never
managed to replicate the environment to try it.

Regards,

Luis L.
Multimedia systems

Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

On Wed, Apr 9, 2008 at 2:24 PM, Luis L. [email protected]
wrote:

BTW, there is a doc or something to help you get the correct
environment to spec RSpec? I saw your pre-commit stuff, but never
managed to replicate the environment to try it.

The pre_commit is not working correctly right now. We’re working on it
though.

El 9/4/2008, a las 20:15, “David C.” [email protected]
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

On Wed, Apr 9, 2008 at 4:04 PM, Wincent C. [email protected]
wrote:

which should probably be mentioned for any patch series which has more

git format-patch

happy and there are multiple changes that should logically be grouped

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.

Thanks for that. I wrote what’s up on the wiki… and to be perfectly
honest, I only care about the end goal of having clean histories to
merge into RSpec core. I also don’t fully understand everything you
wrote. If you had some time, perhaps you could take the existing
content, add some concrete examples of your techniques, and extract
all of that to a new page. I would certainly be very grateful :slight_smile:

Pat

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs