Friday, December 14, 2007

To Git, or not to Git.

I just read Joe Moore's (Pivotal Labs) thoughts on the Linus Torvalds' Git talk that was presented at Google.

I had also watched Linus' Google Talk video about a month ago, and had been hearing about Git in the Merb IRC room.

Git: A cruel piece of software?
The chairman introducing Linus describes Git as "a revision control system which is expressly designed to make you feel less intelligent than you thought you were" and as "a software tool which only he [Linus] is smart enough to know how to use." Was he joking or partly serious? I wasn't entirely sure.

With that preface, I had the impression that using Git was going to have a cliff like learning curve. Nevertheless, I decided to give it a try so I could at least know what others were talking about.

A collaboration of 1
Unlike Pivotal Labs, I'm just a solitary developer using SCM to track changes on my own code. So my needs are fairly limited. I don't really have any "collaboration" needs.

For someone with my limited SCM needs, probably any SCM would work just fine.

Initial thoughts
After using Git a bit, here are a my basic thoughts.

  • It's actually not too difficult at all (at least at a basic user level).
  • It is a command line tool. That's fine for me, as I always have a terminal open anyways.
  • Basic commands are easy to remember: "git status", "git add", "git commit", "git push"
  • It's pretty easy to setup custom ignore files and setup a remote repo.
  • Committing locally is fast & independent of your internet connection.
  • Deployment via Capistrano (v2.1) supports Git.
It appears that branching and merging are very easy, but honestly I don't really do too much (ok, any) of either. I will experiment with that in the future to see if it adds any value to my specific work flow.

You won't find the same level of application support for Git as SVN at the moment. For example, the other day I read about the release of SVNmate, a bundle for Textmate which adds some SVN status icons to your files. There currently is not a bundle offering the same for Git (although there is a bundle "work in progress"). Not necessarily deal-breakers, but things to be aware of.

Personally, I'm going to continue using Git and become more familiar with it's capabilities.

NOTE: Git does have the gitk command which opens a GUI. I haven't used it, other than a cursory glance, and thus am not familiar with it's features.

Related Resources:
Git Cheat Sheet: http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html
Git Tutorial: http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

Monday, December 10, 2007

Merb Tidbit: Logging

Merb has it's handy built in Mongrel server, so you can easily start it up while developing with:

merb
However, you may wonder "Why isn't it generating any log files?"

Well actually it is, but the deal is they are all being output to the command line instead of being written to a file in the log/ directory. If you want to have them written to a log file, you need to start Merb up as a daemon. This is simply done like so:
merb -d
Now your logs will be written to the log/ directory. To stop the background merb process, use the -k PORT flag. For example, if you are running on port 4000 (which is the default) you would use:
merb -k 4000
You can also control the level of detail to be logged using the -l flag. Optional logging levels which can be passed with the -l flag include: DEBUG, INFO, WARN, ERROR and FATAL.

That's today's Merb tidbit. Happy Merbing!