“Awe, for the love of crumbcake!” – Morris Szyslak
Recently I’ve dealt with a handful of newer open-source offerings in the Ruby on Rails community, via GitHub. Newer codebases are more prone to rapid change. Sure enough, I’ve fallen victim to changed code from one download to the next. This can cause a host of problems such as changed syntax, version clash with other plugins, or occasionally just outright bugginess.
If you’re dealing with gems, versioning is built right in, and you can usually get older versions of what you want. Plugins, engines, or base applications are a different matter. My battle cry is this: USE TAGS IN GIT!
First, if you’re using someone else’s code on GitHub, look for the tab that says “All Tags”, and see if there are specifically released versions. This is helpful if you downloaded the latest version and realized it’s totally different from the one you know and love. You can select the version you want, and you have two options from here. Click “Download” to choose the specific version you want, especially if you don’t want the full repository with commit histories, etc. Or, clone the entire app, and switch versions locally. The Spree shopping cart allows this:
bellmyer$ git clone git://github.com/railsdog/spree.git test-spree Initialized empty Git repository in <...> remote: Counting objects: 28927, done. remote: Compressing objects: 100% (10583/10583), done. remote: Total 28927 (delta 17195), reused 28757 (delta 17040) Receiving objects: 100% (28927/28927), 13.08 MiB | 1840 KiB/s, done. Resolving deltas: 100% (17195/17195), done. bellmyer$ cd test-spree/ test-spree$ git checkout v0.9.0 Note: moving to 'v0.9.0' which isn't a local branch If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 78f0b8c... fix typo on option test-spree$ git branch * (no branch) master
Git will inform you (as it did above) that you can’t actually edit the code since the tag is a static snapshot of the repository. However, it also tells you how to create a new branch based on this tag if you are interested in making changes. Easy!
Now, the more important part of my message. To developers who actively publish open-source code, first: thank you. Second, I offer a new TATFT: Tag All The Fucking Time! It’s easy. I’ll prove it, using my test-driven fork of Dave Currin’s Seed CMS.
seed$ git tag 0.0.1 master seed$ git status # On branch master nothing to commit (working directory clean) seed$ git push Everything up-to-date seed$ git push --tags Total 0 (delta 0), reused 0 (delta 0) To email@example.com:bellmyer/seed.git * [new tag] 0.0.1 -> 0.0.1
In the two times I’d downloaded this app in the last month, fundamental pieces had changed, which slowed down my development. If it’d had tags already, I could have chosen to download the version I was already familiar with. I forked his repository to add tags, and to fix the test suite. Feel free to use it if you wish.
By the way, I am NOT harping on Dave Currin’s lack of tags or tests. He’s a very cool guy who admits it needs work, but wisely chose to release a very alpha version of his CMS early, rather than wait forever until it had all the polish of a mature app. I’m grateful, because that choice means I got to use it on two projects so far. Well worth it.
In conclusion, tags are so easy in Git and GitHub, both for the publisher and the user, that there’s no reason not to use them.