Howdy Rip! »

Created at: 11.06.2009 20:35, source: Robby on Rails, tagged: Ruby on Rails ruby programming ruby rubygems gems git github rubyonrails development

Chris Wanstrath (@defunkt) just posted the following on twitter.

“Hello Rip – http://hellorip.com/“

The Rip project describes itself as, “an attempt to create a next generation packaging system for Ruby.”

One of the cool features is that it supports multiple environments. For example, you can have different Rip environments (with different gem versioning) that are targeted towards specific applications. I have to dig around more through the project, but this looks fascinating.

Check it out at http://hellorip.com/

I’m also curious as to how you think you might be able to start using this.

What are some ways that you could use Rip—http://heybrainstormr.com/t/pgte

more »

Git commit-msg for Lighthouse tickets »

Created at: 16.02.2009 21:51, source: Robby on Rails, tagged: programming git lighthouse github workflow bash

A quick follow-up to a post from a few months ago on how our team has a naming convention for git branches when we’re working on Lighthouse tickets (read previous post).

I’ve just put together a quick git hook for commit-msg, which will automatically amend the commit message with the current ticket number when you’re following the branch naming conventions described here.

Just toss this gist into .git/hooks/commit-msg.


  #!/bin/sh

  #
  # Will append the current Lighthouse ticket number to the commit message automatically
  # when you use the LH_* branch naming convention.
  #
  # Drop into .git/hooks/commit-msg
  # chmod +x .git/hooks/commit-msg

  exec < /dev/tty

  commit_message=$1
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  branch=${ref#refs/heads/}

  if [[ $branch =~ LH_(.*) ]]
  then
  lighthouse_ticket=${BASH_REMATCH[1]}

    echo "What is the state of ticket #${lighthouse_ticket}? " 
    echo "(o)pen " 
    echo "(h)old" 
    echo "(r)esolved" 
    echo "Enter the current state for #${lighthouse_ticket}: (o)" 

    state="open" 

    read state_selection

    case $state_selection in
      "o" )
        state="open" 
        ;;
      "h" )
        state="hold" 
        ;;
      "r" )
        state="resolved" 
        ;;
    esac
  echo >&2 "[#${lighthouse_ticket} state:${state}]" >> "$1" 
    exit 0
  fi

Then a quick example of how this works…


  ➜  bin git:(LH_9912 ♻ ) git ci -m "another test" 
  What is the state of this ticket? 
  (o)pen 
  (h)old
  (r)esolved
  Enter the current state: (o)
  h
  Created commit 1ed2713: another test
   1 files changed, 3 insertions(+), 1 deletions(-)

Now to see this in action… (screenshot)

Then we’ll check out the git log really quick.


➜  bin git:(LH_9912) git log
commit 1ed271323c4a054fe56e76bddc9ac81d241a1032
Author: Robby Russell <robby@planetargon.com>
Date:   Mon Feb 16 12:06:33 2009 -0800

    another test
    [#9912 state:hold]

Thanks to Andy for helping me figure out how to read user input during a git hook.

more »

Mephisto: Change from SVN to Git »

Created at: 19.04.2008 18:24, source: poocs.net - Home, tagged: git git mephisto subversion

The fine folks over at ENTP/ActiveReload have released version 0.8 of Mephisto, the Rails application that powers this site. With this new release, they, as everyone these days, have actively shifted the remaining bits and pieces of Mephisto’s development from Subversion to Git. (And its main repository is hosted at Github, where else.)

I hardly remember ever installing Mephisto from a tarball. I always used to track its Subversion trunk for the 3 blogs I run, which made upgrading as easy as svn up && rake db:migrate RAILS_ENV=production most of the time. Well, that was then and this is now. Looking at this recent shift to Git, I wanted to convert my blogs to the new Git repository without excessively messing with whatever I did to my local installation (quickly approaching my 30s, I might not even recall most of what I did). I was pretty certain, however, that I did not have massive local modifications. If I had, this approach might’ve been a little simplistic.

Here’s what I did.

Initializing

Starting out, you need to create a local Git repository within your local blog installation, which is as simple as:

$ cd /your/blog
$ git init
Initialized empty Git repository in .git/

The next step is to setup technoweenie’s master repository on Github as a remote to your local repository and fetch what’s currently in there.

$ git remote add technoweenie git://github.com/technoweenie/mephisto.git
$ git fetch technoweenie
remote: Generating pack...
...

This will fetch both the master branch and all branches technoweenie might’ve created. (This includes, for example, a branch that holds the current 0.8 release, if you don’t dare to ride the edge of Mephisto’s development.)

Merging

At this point we need to merge one of the branches we just fetched into your local (totally empty, for what it’s worth) repository. (I’ve decided to stay on the master branch. If you prefer a release branch, substitute it as appropriate.)

$ git merge technoweenie/master

Since Subversion scatters its .svn folders all over the place, we need to get rid of those. You can either do that manually or with a little find-fu.

$ find . -type d -name '.svn' -exec rm -rf {} \;

Excellent, that’s much better. Now it should be safe to check out the current state of affairs:

$ git status

Running this command will show you the currently untracked files. Those would be all files that existed locally before you started to create your own Git repository and which are non-existent in technoweenie’s repository.

Tracking local modifications

As I mentioned above, I didn’t have a boatload of local modifications. My changes were limited to bit of configuration, a few third party plugins (and the accompanying CSS/Javascript) and my local Mint installation. The additional files and directories that may show up are the cached HTML files that Mephisto sticks in public/.

To actually add your local modifications to your Git repository, simple add and commit them.

$ git add config/mongrel_cluster.yml
$ git commit -m 'Mongrel configuration'

If you’d prefer to rather ignore whatever else sits in your blog directory, add it to .gitignore

$ echo "public/*.html" >> .gitignore
$ echo "public/200*" >> .gitignore
$ echo "public/mint" >> .gitignore
$ git commit -m 'Ignore cache and mint' .gitignore

Cleaning up

I had a few files sitting in my directory that weren’t local modifications but seemed to have been removed from the official repository, too. Those weren’t caught by our merging of the Git branch since we started with zero history. To get rid of those, let’s take a look at git-clean.

$ git clean -n -d
Would remove app/views/admin/article_comments/
Would remove app/views/admin/articles/approve.rjs
Would remove app/views/admin/articles/comments.rhtml
Would remove app/views/admin/articles/destroy_comment.rjs
...

The -n argument prevents git clean from actually doing anything. If you’re confident it wouldn’t do anything harmful, go ahread and remove it. (You do have backups, right? Do you?)

At this point we’re down to regular upgrading business, so you might want to run the migrations and restart your Mongrel cluster. (Or whatever floats your deployment boat.)

$ rake db:migrate RAILS_ENV=production
$ mongrel_rails cluster::restart

Into the future

Now, whenever Mr. Weenie adds an exciting new feature to Mephisto you can grab that via:

$ git fetch technoweenie
$ git merge technoweenie/master

Or if you’d rather prefer to pick a specific commit:

$ git cherry-pick <SHA1>

A quick note for gitHub users. If you browse your repo you won't see the vendor/rails folder and might freak out. Don't! Git is smart and wants to stay slim, instead of copying the files over, it just creates a reference to the original repo. If you try to pull your project in another folder you will see that the Rails folder gets created as expected.

Personally, when plugins are not available in a git repo I usually do a simple svn export to my project vendor's folder. If I need to modify one of these plugins, I just import it to github and work on it from there.

You might still want to stick to Piston or Braids and that's fine, but now you won't have an excuse not to switch to Git :)

UPDATE: I just found out that Graeme wrote a nice detailed post about tracking plugins using git, check it out

more »

Freezing Rails with Git »

Created at: 16.04.2008 11:21, source: Rails on the Run - Home, tagged: freeze git rais

As you've probably heard, Rails now moved to its own GitHub repo.

If, like me you were a heavy piston user, you are wondering how you will be able to do the same thing if you switch to git.

First off, you need to know that Piston will soon support git. As a matter a fact it already does. At least you can download a beta version from François's blog.

You can also go with giston/braids which was meant to make the svn/switch easy on you. I heard rumors that evilchelu might not keep on developing this project. You might want to check with him.

Personally I didn't really like using any of these solutions. Rails also came with its' own approach. (rake rails:freeze:edge)

When I recently worked on Merb's freezer, I discovered the power of git submodules.

Submodules allow you to import "modules" from other git repos inside your own repo. Basically they do what piston does for SVN, apart that submodules are built-in git. Of course it has an expected limitation, you can only add git submodules.

The good news is that Rails moved to git and now you can "freeze" Rails as a submodule and update really easily!

First thing first, you need to move your project to git. If you are not confident it's a good move yet, you can use "git-svn". However, I would personally recommend you don't. I did that for few months and when I finally moved to git only, it was a pain to restructure the entire path of the app.

Anyways, let's say you created a new github project and if still wish to use git svn do:

1234	$ git-svn import svn://path-to-your-svn-repo project-name$ cd project-name$ git remote add origin git@github.com:mattetti/project-name.git$ git push origin master

Your project is now under git, but if you pistonized Rails, you can't update it anymore :(

Do not fear my dear friend and do as follows:

$ rm -rf vendor/rails
$ git commit
$ git submodule add git://github.com/rails/rails.git vendor/rails
$ git submodule init
$ git commit
$

That's it you are done :)

Next time you want to update just do:

123	$ cd vendor/rails$ git remote update$ git merge origin/master

or you can also do

12	$ cd vendor/rails$ git pull

(yes, each plugin acts a a normal git repo)

A quick note for gitHub users. If you browse your repo you won't see the vendor/rails folder and might freak out. Don't! Git is smart and wants to stay slim, instead of copying the files over, it just creates a reference to the original repo. If you try to pull your project in another folder you will see that the Rails folder gets created as expected.

Personally, when plugins are not available in a git repo I usually do a simple svn export to my project vendor's folder. If I need to modify one of these plugins, I just import it to github and work on it from there.

You might still want to stick to Piston or Braids and that's fine, but now you won't have an excuse not to switch to Git :)

UPDATE: I just found out that Graeme wrote a nice detailed post about tracking plugins using git, check it out

more »

bgror

Ruby on Rails Planet

Howdy Rip! »

Git commit-msg for Lighthouse tickets »

Mephisto: Change from SVN to Git »

Initializing

Merging

Tracking local modifications

Cleaning up

Into the future

Further reading

Freezing Rails with Git »

Freezing Rails with Git »

Tag cloud

Categories

Links