Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Lesson Learned: Git Ref Naming

Posted by Fri, 19 Sep 2008 03: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.


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. :-)

Embracing Chaos, part 1

Posted by Tue, 18 Dec 2007 03:21:00 GMT

Consider this part one of several posts on my thoughts of the art of embracing chaos.

Don’t let the books fool you. The construction of custom software is an unmastered and volatile cesspool of chaos. I don’t adhere to the belief that there is a perfect methodology or process that will work for every project… as I’m sure many of you don’t.

Unlike bowling, you’ll never achieve a perfect score. Even in bowling, It’s unlikely that anybody will learn how to bowl a perfect score and do so on every game for the rest of their career.

You’ll never meet every expectation that a client has on every project.

You’ll never meet every expectation that a user has when they interact with your application.

Expectations are an interesting thing.

Your project might get widely adopted and embraced, but you’re still trying to control chaos.


It’s chaos. Pure chaos1.

So, why do we bother? Why do we try so hard when the odds aren’t in our favor?

To be continued…

Related Posts:

1 Chaos Theory, Wikipedia