Ben Chinn

Slightly nerdy ramblings and linkage

Getting into Git

Over the past few weeks I’ve been overtaken by a strange new obsession. I’m talking about Git, the version control system created by Linus Torvald and used for developing the Linux kernel as well as numerous open source and private software development projects and other kinds of digital work (even books). I’ve read a number of books on the subject, got myself a github account and even started evangelizing for Git at my svn using workplace. I’ve never paid attention to any VCS before. How did this happen?

Harder is better

One thing I like about got is that it is contains, for me, just the right amount of complexity. The basic operations are fairly simple but there are numerous parameters that can be added, configurations to be customized and advanced methods to be used. I’ve been researching and using Git for a couple of weeks and feel like I’ve just scratched the surface. That’s one of the reasons I’m attracted to the system: it affords opportunities to learn and gain mastery.

But it’s not just advanced operations that are more challenging. Even the simple act of committing a file is more complex in Git than is other VCS like subversion. In Git committing is a two step process: first you stage changes, then commit them. (Actually committing can be made simpler by using “commit -a” to add and commit a the same time but that isn’t the default behavior.) Yes, this creates an extra step and so is “harder” than other systems but the benefit is worth it. Staging changes together encourages you to be thoughtful about what is going into each commit. That pays dividends when you have to use your commit history later or somebody else needs to review your work.

Sharing is Caring

The same is true of the way that committing and pushing are two different steps. In a centralized VCS a commit will be automatically shared with everybody when they update from the centralized repository. In Git the commit happens locally and only gets shared when the local repository is pushed to another clone. M the local history can be changed (commits squashed together, messages changed, etc.) in the interest of making the repository’s history better for public consumption. This means that the user can commit fast and share slow. Those two tasks get treated differently because they are different and require different thought processes. You could say that this is harder than just committing changes and making them public at the same time and you’d be right, but easier is not better in this case.

Digging In

I still work with Subversion, I have to since that’s what’s used in my office (at least until I win everybody over to Git). Recently I have been using Git with git-svn (thanks to this article) so it acts as a client for the central subversion repository. At last version control doesn’t feel like a chore any more. Every day there’s a little satisfaction in using a tool better than I did before. There’s a host of decent GUI Clients, including my favorite, Gitx but I find I’m using the command line more and more. I want to be a power user not just a drone punching “svn commit” and “svn update” into my terminal all day. Git has freed me up to be as nerdy as I want to be.

In Defense of Tweaking

Whether you’re customizing your application preferences, changing your desktop background or adjusting your workflows you are guilty of the sin of tweaking: the act of altering a process that has no immediate or direct impact on the product of that process. I am here to say that tweaking is not a waste of time but is a valuable activity with many benefits.

Tweaking is Learning

When I start using a new piece of software it’s not long before I start mucking around with the preferences and seeing what I can change around. This can be a great way to learn what the software can do. If I were to just start using the application to produce something I’d probably be replicating whatever behaviors I’m already comfortable with. Fiddling with the software gives me the opportunity to see what the new application does better or differently and then modify my usage accordingly.

Downtime

If I’m between projects or just feel like I need a break I’ll often start tweaking stuff. This means I’m still engaged with the processes behind my work even if there’s no work to be done. Then when I pick up a new project it doesn’t feel so much like a cold start; I haven’t put my toolbox down so there’s no effort in picking it back up. In other words, tweaking my tools keeps me in the flow of work even when the work itself has come to a halt.

Sometimes it really works

There are times when changes in process lead to improvements in the product, when exploring the tools of production leads to making something new, interesting or just better. This blog is a case in point: I’ve blogged before, using Blogger, Wordpress and Textpattern. I got tired of blogging mostly because those tools just didn’t seem to fit any more and it wasn’t any fun for me to keep working with them. It wasn’t until I discovered Jekyll that I could see myself blogging again and it wasn’t until I’d fiddled around with my setup for a while that I was ready to start writing.

Where does it end?

There’s a fine line between useful tweaking and empty procrastination, a line that separates the productive from the idle, the focused from the distracted. At some point you’ve got to reach a point where the tweaking stops and the real work begins. I just hope I’m staying on the right side of that line while I’m exploring new tools and playing with the ones I have for the most important reason I can think of. It’s fun.

Tools

Tools are important. I once spent 6 months renovating a house and although I didn’t really know what was doing I was lucky enough to be working with somebody who did. This is the advice she gave me: use the right tool for the job and make sure your body is in the right position when you’re using it. Following this advice got me through many home improvement tasks efficiently and without injury. Surely it’s a different story when we’re talking about knowledge work though, right? Let’s see.

Use the right tool for the job

Even for those of use sitting in an office in front of a computer screen all day this is important.

  • Windows or Mac or Linux?
  • Vim or Emacs or Textmate or [insert other editor here]?
  • Sitting or standing?
  • Subversion or Git?

These are meaninful questions and the answers make a difference. Everybody in my team at work uses a Mac. I believe this gives my work environment a different character from the offices I’ve worked in where folks were on difference platforms or were all on Windows machines. I think it’s that my team feels less “corporate” even though we work within a corporate environment. Are Macs better? Maybe. What’s for certain is that they evoke a different response in their users and they are more conducive to certain kinds of work. As Doug Rushkoff argues in his book, Program or Be Programmed technologies have biases that we generally take for granted. Using the right technology means making these biases work for you.

Put your body in the right position

This comes down to using the tool correctly. If you love vim but find you’re spending half your day creating macros then maybe you need an editor that gives you less opportunity to fiddle. If you’ve got 100 emails in your inbox each of which you read every time a new message comes in then maybe you should be taking a different attitude toward your mail application.

All this being said, what are the tools that I use?

  • A iMac at home and MacBook Pro in the office.
  • Transmit, iTerm2 for web development.
  • Safari and Chrome for web browsing.
  • Apple Mail.app for work emails, Sparrow for personal messages through gmail. I’ve been going back and forth from Mailplane and Sparrow and am still not sure what fits me best.
  • TextExpander, Keyboard Maestro and Launchbar. These three help me automate or speed a bunch of tasks I perform every day.
  • Omnifocus for task management
  • iPhone and iPad. I use calendar and address book almost exclusively on iOS rather than the mac.
  • Multiple tools for writing and coding. Textmate is the heavy hitter in this department and I’ll second those who say that even with its flaws and lack of visible development it still does a terrific job. I also use Nvalt for tracking text files on the Mac and a bunch of apps on iOS: Simplenote, Notesy and Writing Kit top the list.

I hope to post more about some of these tools and how to make the best of them.