Read my latest article: Ezra Zygmuntowicz -- Farewell, Friend. (posted Mon, 01 Dec 2014 17:53:00 GMT)

Oh My Zsh gets theme support

Posted by Mon, 31 Aug 2009 15:00:00 GMT

I just pushed a small change to Oh My Zsh, which gives it rudimentary support for themes. What I’m hoping to do is collect prompts from tons of people and make it simple for others to find a PROMPT that works well for them.

robbyrussell's oh-my-zsh at 2c9f74b5c3f6910e7c66601008e9ddd0444b70c7 - GitHub

As of right now, there are only three for you to choose from. So, please head over to github, fork Oh My Zsh, add your theme, and send a pull request. :-)

zsh /Users/robbyrussell/Projects/development/planetargon/brainstorm 2014 zsh

Once I get it merged in, we’ll get a screenshot of it added to the Oh My Zsh wiki. (see themes)

I know that many of you have some really sweet prompts configured as I got a lot of response with my post, Show me your and I’ll show you mine.

..and on the seventh day, Science created zsh

Posted by Mon, 31 Aug 2009 01:08:00 GMT

Inspired by some recent posts from Tom on zsh, I decided that I’d do my part to help people give it a whirl. I’ve been using zsh for a few years now and haven’t found myself missing bash.

If you’re interested in taking a few minutes to give zsh a while, you’re in luck. I recently reorganized all of my zsh config into a package and tossed it on github to share. My goal was to create a reusable tool that would allow people to get up and running quickly with some of the fun configuration that I’ve come to rely on on a daily basis.

For example:

  • Auto-complete rake and capistrano tasks
  • Git branch names when you’re in a git project directory structure
  • Tons of color highlighting (grep, git, etc.)
  • Sexy prompts.. (so say me)
  • much much more…

I invite you to give Oh My Zsh a whirl, which should take you less than a minute. Just follow the instructions.

Also, Oh My Zsh is Snow Leopard compatible. ;-)

Howdy Rip!

Posted by Thu, 11 Jun 2009 17:35:00 GMT

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.

Git commit-msg for Lighthouse tickets

Posted by Mon, 16 Feb 2009 19:51:00 GMT

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)

git message hook

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.

Lighthouse tickets and Git branching

Posted by Thu, 11 Dec 2008 17:36:00 GMT

We’re currently using Lighthouse as our ticketing system with clients for maintenance/bug requests. We’re also using Github for all of our major client projects. I’m sure that many of you take advantage of the Lighthouse service that Github allows you to use so that your commits can trigger actions on your tickets in Lighthouse.

If you’re not already, you might consider running (cheat ?):

  • cheat lighthouse

lighthouse:
  - Commit comment [#213]
  Adds message as comment to ticket #213

    * tagged - adds tag to the ticket (does not replace)
    * responsible - sets the user responsible for ticket (responsible:none to
    clear)
    * milestone - sets the milestone for ticket (milestone:none to clear)
    * state - sets state (new, open, hold, resolved, invalid)

  - Commit comment [#213 tagged:committed responsible:johan milestone:"Launch" 
  state:resolved]

With your commit messages, you can just pass in the ticket # and resolve your ticket without needing to interact with Lighthouse too much.

Okay, so one of the problems that I’ve had with this process is that I have had to constantly look back in my browser to see what the ticket # was that I was working on. So, I decided to start writing it down on a notepad as I was working through tickets so that I could look down at my desk, but this wasn’t terribly efficient either.

So, I decided to start leveraging the features of git to help me out. For each ticket that I work on, this is my process.

In Lighthouse, I decide which ticket I’m going to work on next. I then create a local branch using the ticket # in the name. Example: LH_1623

The workflow ends up looking like:

alphaclone git:(master): git checkout -b LH_1615

alphaclone git:(LH_1615): <—I am using zsh and have it display the current local branch

I then work on this ticket. Since I’m working within the branch and my prompt reminds me what ticket # is being worked on, it makes it easy for me to add this into my commit message.

git commit -m "Fixed the do-whacky issue with data importing. [#1615 state:resolved]"

At some point, this will be ready to be merged back into master and pushed to Github.

git checkout master

git merge LH_1615

git push origin master

Github will take your commit message and pass it over to Lighthouse and your ticket will be marked as resolved automatically. This workflow has saved me a lot of time from navigating through Lighthouse and has also helped me stay focused on individual tickets throughout the day. Quite often, I’ll get interrupted by something non-development related and seeing the ticket # in my terminal helps get me back on task.

I’ve managed to encourage a few of the others at Planet Argon to adopt this ticket-based branch process as well so that when we need to collaborate on a ticket we publish the ticket branch to Github so that others can work on it as well. (happens a lot when a designer and developer need to work together on the same issue/feature)

Anyhow, just a quick little introduction to something simple that I did that has definitely helped me become a little more efficient throughout the day. Perhaps you have a better approach and/or tips for others that you’d like to share?

Related Posts

Lesson Learned: Git Ref Naming

Posted by Fri, 19 Sep 2008 04:23:00 GMT

Our team has been working our way into the Git world. One of our big client projects is now 100% git while the other is still on Subversion for another month or so. (I’m getting by with git-svn, the gateway drug on that). We’ve had pretty much nothing but success with Git for quite some time, but recently this repository started to get chaotic, which has eaten up time… which isn’t conducive to productivity.

So, I wanted to share a quick lesson that we learned today after scratching our head for a while. It’s important that you avoid having a branch on a remote repository that shares the name of a tag in your local and/or remote repository.

I REPEAT.

It’s bad mojo to have a tag and branch share the same name. Things that you’d expect to just work... don’t. This was causing us to see warnings and errors like the following, which we weren’t really sure what to make of it.

“warning: refname ‘staging’ is ambiguous.

“error: src refspec staging matches more than one.”

This started about two weeks ago when we started a few new remote branches: staging and design. It seemed to be going okay but we managed to muck up things when we merged those two together and some of us were having success fetching/pulling/pushing to staging and others were having to specify :heads/staging and couldn’t have a local branch named staging. Needless to say, it was causing some problems and slowing us down.

This afternoon, we finally noticed in the GitHub interface that there was a tag named staging. Hmm… interesting. We verified this by using git show-ref.


git:(master): git show-ref | grep staging
6a18119ca9.... refs/heads/staging
82caa5f121.... refs/remotes/origin/staging
6a18119ca9.... refs/tags/staging

Notice the tag reference at the end? After asking in #git, we were able to remove the tag with the following:

git tag -d staging

Then we needed to remove the reference of staging on Github with git push origin :staging. (we got rid of the remote branch temporarily as well so that we could clean this up).

The next step was to push our local branch back out to the remote branch git push origin staging:staging.... and now we’re back in business with a simple:

git checkout --track -b staging origin/staging

Anyhow, if you end up having those warnings/errors above, you might take a look at git-show-ref to see what is in your local repository as this could be causing you some unnecessary headaches.

Kudos to Allison for taking the time to really read and digest the git documentation, which helped us figure this shit out. :-)

Since we’re still learning to get around through things like this, if you have any more insight into this issue, feel free to help educate us a bit by sharing your wisdom in response to this post. :-)

Older posts: 1 2 3