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 Chelimsky <dchelimsky at gmail.com> wrote:> It''s official: http://tinyurl.com/5npxxb > > Git some happiness! > > Cheers, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- George Anderson BenevolentCode LLC O: (410) 461-7553 C: (410) 218-5185 george at benevolentcode.com
On Wed, Apr 9, 2008 at 2:43 PM, David Chelimsky <dchelimsky at gmail.com> 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 Lavena 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 Lavena <luislavena at gmail.com> 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 Chelimsky" <dchelimsky at gmail.com> escribi?:> > It''s official: http://tinyurl.com/5npxxb > > Git some happiness! > > Cheers, > DavidOne 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 Colaiuta <win at wincent.com> wrote:> 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.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 :) Pat