Mobile office essentials - the optimized list

Having worked 99% remotely now for 9 years I believe I've got my mobile office nearly optimized. 

Here is the list of exactly what's need - no less and no more:

  • Noise canceling headphones - At a coffee shop there is only a 5% chance that they're playing music you find tolerable and 2% it's enjoyable. It's also likely to be either way too loud or the only seat is right under a speaker. The head phones must have a hard case to protect them in your bag. These are mid-to-low end JVC ones I've found suitable for four years:  Pro-tip: Carry a couple spare AAA batteries too or whatever.
  • Sigg water bottle - You need to stay hydrated and avoid plastic. Even more important is something that will never ever ever leak. An aluminum 1L Sigg is perfect.
  • Spare power cord - This should live in your backpack otherwise you'll get to the coffee shop and realize you forgot it
  • Power outlet expander - There is a 30% chance the outlets will be taken, 90% if you're at an airport. Something like this is ideal. Small, light, cheap, but invaluable. I get complimented every single time I pull this out when outlets are at a premium:
  • Suitably powerful laptop - There is pretty much no reason to have a desktop at this point as your work computer. Yet I'm shocked on a daily basis at how much time people waste waiting for the laptops to boot, shutdown and spin around. A good machine pays for itself in a few months of more productive work if not weeks. Pony up!
  • A baseball type cap - As the sun moves across the sky you'll eventually have light at the top of your vision or a car will park with it's windshield focusing the light laserlike at your retinata. A baseball cap can mitigate this annoyance. 

That's everything you need for the perfect mobile office. Happy mobile computing!

Introducing GitPrime - auto save for your local Git repositories

What is GitPrime in nutshell

 Before I forget here is the link :)

GitPrime is essentially autosave for a local Git repository. Actually it can be run against multiple local git repositories. 

Basically it is a script when run saves the state of your local Git repo whether the working directory is "clean" or "dirty".

I created it because I've really enjoyed an IntelliJ feature called Local History. If you screwed something up you could look back, compare files, figure out what you broke and dig yourself quickly out of an otherwise giant hole. This happened a lot more before switching to Git where checkins are more frequent, but still happens.

What GitPrime gives you:

It gives you access to your repo's contents at any point in the past (till Git cleans things up every two weeks by default). It is meant to 'save your assets'.  :)

Everytime GitPrime is run on a dirty working branch it creates a "commit objects" which is like a stash, but not saved on the 'stash stack'.

GitPrime also creates a log file called gitPrime.log which appends the hashes of these "commit objects".  Such an entry looks like this:

a0af37fd4e20297da159d298237b0acd0bd19302 Sun Oct30 22:38:19 MDT2011 branch: (master) – stash object created by git-prime (DIRTY Working Directory)

2233ee41f42ee05f50bb31a04a2b3f6e524664d5 Sun Oct30 22:38:43 MDT2011 branch: (master) – HEAD hash captured by git-prime (CLEAN Working Directory)

760e7e36e4233b3676cae28189d9f58665aedf68 Sun Oct30 22:38:58 MDT2011 branch: (master) – stash object created by git-prime (DIRTY Working Directory)

Using these hashes you can then do something like:

git diff a0af HEAD - which would give you the differences of your current branch HEAD and some previous state


git branch branchname a0af - which would create a new branch from your auto-saved repo from hours or days ago. Cool!

To find these entries you can look at the gitPrime.log file in the top level dir. of your repository.

You can also run gitPrime manually. Once it is in your path just type and all your work will be instantly saved but your directory will be completely unaffected. 

How GitPrime is different than "git stash":

It does not affect your working directory at all. It also does not affect the git 'stash'. It is meant to be run continuously by a cron job. 

Otherwise it does work like "git stash" and only tracks stuff committed or added to the index. 

The git commands GitPrime uses:

git stash create

This creates a 'commit object' like a stash, then the script writes out the hash to the gitPrime.log with a bit of meta-data. 

But if your working directory is clean then this command gets no hash back. Then the script knows you're on a clean branch and it grabs the HEAD hash and writes that out using:

git rev-parse HEAD 

In both cases before it writes to the log it checks to see if that hash (or an equivalent hash obj with no differences) was just written. If so then the script does not write anything to the log - nothing changed.

Are there any downsides? Only a bit of space

The only thing to know is that every time GitPrime is run against a dirty working branch that it uses 8k of storage. This is small but can add up.  If this runs every ten minutes for a day then it will use ~1 Meg of storage.

However if your branch's working directory is 'clean' / 'committed' then no space is used. GitPrime just records the hash of the current HEAD.

Every two weeks by default Git will clean up all these 'dangling' commit objects that are not reachable via any branch. 

So unless you change the default setting then each repo with a dirty working dir would use up about 14 Meg of space (if a cron job runs it every ten minutes).

If you want to recover this space immediately you can run:  git prune   (though git recommends not running this).  You will loose all of those commit objects.  Your branches will not be affected.

If you want to see how much space is being used you can do a "du -kh on your .git" directory, then run the script a few times manually and look at the difference. 

Where the name comes from:

I started out trying to sort of local tracking branch. This didn't really work and sort of gimped the history. I was going to call such a branch a 'prime branch' hence the name Git Prime. Even though I completely switched strategies the name stuck. 


  1. download the files into some directory like 'gitPrime'
  2. update the file to point at the git repositories you want to enable for 'gitPrime' tracking. This should be obvious but just replace these entries "<another-git-repository-path>"
  3. create your cronjob to run     My cronjob runs every ten minutes and looks like this:

*/10 * * * * /bin/sh /Users/brendan/projects/git-prime/

4.  (optional) It is a good idea to add the file gitPrime.log to your .gitignore file. 

That's it!  Three steps that should take less than 5 minutes.

Bonus:  If you add '' to your path then you can run it manually anytime. 


Link to GitPrime

GitPrime is a script that works like an auto-save on a git repository.  It is efficient just like Git.  And you will barely know its there until you need it - it does not change your working directory or your git history or anything you can see through any 'common' git commands (unless you REALLY dig). 

Hope you find this helpful! Would love to hear comments. 

My top X reasons for moving to DVCS (Git)

I'm trying to polish a better 'DVCS elevator pitch'. Here are my top X reasons to move to DVCS:

  1. Cheap commits are simply fun. Seriously! When you can commit with reckless abandon unconcerned without screwing up anyone else's work it's a great way to punctuate the start, middle or end of any coding session. When your commits are local you simply WILL make more of them. Having those additional commits, the history and comments that come with them are like having a whole new tool in your toolbox - a really useful new tool. 
  2. That richer commit history which is always available  can literally save your ass. Pardon my French. Just in the last two weeks I was working furiously on a piece of software I was going to demo to an audience of couple hundred people. If I wasn't such an amateur I'd have put in place a feature freeze. But of course I completely busted it minutes before the demo. Thank the software gods (Linus?) I had tagged a commit earlier in the day that had the basics working.  I 'stashed' my current work and checked out that functioning version. Did I mention the network was down?  Subversion would have been a double FAIL here - needing a network AND even if I'd gone to the relatively significant pain of setting up Subversion/CVS/Perforce/VSS repo I would not have made as many commits. Git saved me from own foolishness....again.
  3. One tool to rule them all and in the darkness bind them. Your customer or employer still use Subversion or Perforce or X? No problem. Git has crazy good Subversion integration so you can basically treat that Subversion repository as a slightly dumbed down remote Git repo, but locally work as you would otherwise (just know you need to rebase rather than merge branches - Google it if you care). I can't speak to Perforce integration but know it's also very popular. 
  4. The cool kids are doing it. I say this not from the perspective of 'trying to be cool' (again an area of significant 'development opportunity' for me). Rather the cool kids are moving to DVCS because of how it improves their work / lives / state of mind.  Has anyone who uses and understands Git/Mercurial switched back to Subversion/CVS by choice? Nope.  That would be like throwing out your new 52 inch HD LCD TV  and opting back for a 12 inch black and white TV. 
  5.  Completely set up a repository in ~9.1 seconds (that's the typing).  Why do I say nine seconds? Its because I just timed myself and how long it takes me to type:   git init; git add *; git commit -m "first commit"; That is all it takes and you are fully ready to go with working repo of the most powerful and feature rich version control system in existence. If you spend five years only working on one giant project you might not care about this point. But if you're like many(most?) developers and have lots of both small and big projects you'll appreciate this.
  6. Your repository doesn't go grow legs and march away without you knowing. I've set up a lot projects in Subversion and so have you. I'd say over the last ten years I no longer have ready access to 90% of those projects. This is because hosting providers move servers and I didn't follow up. Or I'm cheap and stop paying a hosted Subversion provider. Or a company I worked with moved/restructured their repo. Or my network drive hosting my repo got lost in a move, etc. OR I'm currently commuting in a plain/train/automobile. Sure I still have the local and most recent snapshot of those code bases but that's it, no history and my current snapshot might not even compile. A Subversion repo is almost never local (because that kind of defeats a lot of the purpose). With DVCS of course you've got a full repo.   It's hard for me to say how great it is now when a customer calls me up and says "Hey remember that thing you did for me a couple years ago? I need an update to it." and at long last I don't get an instant headache wondering where that Subversion repo went I used to use with it.
  7. Imagine a world where "branching" and "merging" weren't dirty words. Then step into that world. There are a lot of reasons why branching and merging with Git and Mercurial work REALLY REALLY well to the point of being almost magical. That could be the subject of several chapters, but the simple reason is branching and merging work well because they have to.  DVCS is only viable because branching and merging work really well. Someone familiar with DVCS won't blink at creating a branch to add three lines of code and then merging it back in. Its just that easy and fast.  Extract from Linus's talk: 

    The only thing that matters is how fast can you merge.
    In git, you can merge... I merge 22,000 files several times a day, and I get unhappy if a merge takes more than 5 seconds, and all of those 5 seconds is just downloading all the diffs, well not the diffs but its the deltas between two trees, the merge itself takes less than half a second.
    And I do not have to think about it.

  8. With Git especially you can do some empowering, wonderful, amazing and yes even frightening things, but you CAN do them. I remember a customer calling about four years ago "I accidently checked in a master password with my source file to the public repository. Please delete it." It was a BIG public subversion repo. This shouldn't be a big deal right?  ROFL!!!  Can you say "pour a minimum of 8 hours of your best admin's time down the drain, schedule downtime and then really get that drink you need"?  With Git if you know the right commands to rewrite history you're talking a few minutes. If you don't know them then add a few more minutes to Google
  9. There is always more to learn. OK this can be seen from two angles obviously both bad and good. Even after years of teaching Git the author of the best selling book on the tool is admittedly still learning things about Git's central commands I think it's safe to say that there is a lot to learn about Git. That being said you can certainly get by with reasonably small subset of commands to satisfy your workflow. With something as powerful and as flexible as Git there is always something new to learn. I believe this to be a good thing strange though that may be. 
  10. Lightning speed. Every operation in Git is incredibly fast and objectively it is the fastest system for almost every operation. Sure a pull or push to a remote repo can be constrained by the network but it's a challenge to find any local operation that takes more than a fraction of a microsecond. 
  11. Tags are NOT RIDICULOUS subver *cough* sion. OK I think this one is just a personal pet peeve but I've always been really annoyed at the way Subversion tells you create tags. Completely copy an entire directory structure? Insanity! Never mind that a tag should be essentially immutable not just a directory of mutable files.  Honestly in Subversion I never saw the reason not to just add to a comment "tag: version 2.1.5" and then grep back for that in the log as needed. Fast, recoverable, not weird and not wasting tons of disk space. Whatever the case, DVCS does it right and creating a tag probably takes literally less than one billionth the amount of time as Subversion. Subversion branches are just as bad, but conceptually at least less ridiculous. 
  12. Bisect FTW! Track down where that broken thing(s) got added that broke stuff. Do so quickly and relatively painlessly with bisect. Many devs choose Git/Mercurial just for this feature. 

Bonus reasons:

The sheer genius of your fix/contribution to that open source project will enshrine your name in the hall of immortal coding giants. But first you must lay prostrate and say "Oh key master of the open source project I implore you to consider my humble contribution. I offer my patch and pray thee won't sit on it for a year."  Or at least that WAS the old way. Now you just fork the project, make your fix and click on pull request.  This is more along the lines of "Hey there, dig your stuff. I made it better. You'll want to merge in my awesomeness and it's only a click away. Or don't and people can pull from me - whatever." I literally lack the words to describe how insanely cool this is. Here is a video.


SourceTree by Atlassian - Mac client for Git and Mercurial Distributed Version Control - now free

If you missed the news, Atlassian acquired SourceTree, a powerful Mac client for Git and Mercurial distributed version control systems (DVCS).  SourceTree is an incredible tool, one we want to make available to as many developers as possible, so we're *making SourceTree FREE *for a limited time. It's available direct or through the Mac App Store.

SourceTree helps with several common developer needs:

  • Get a team up and running using common Git and Mercurial commands from a simple GUI
  • Manage all your repositories, local or hosted, through a single, simple client
  • Commit, push, pull and merge changes easily
  • Advanced features such as patch handling, rebase, stash/shelve and much more

DVCS features made easy

SourceTree is packed with features to help both novice and advanced users.  Some of the feature include:

  • Create and clone a repo
  • Review outgoing and incoming changesets
  • Detect and resolve conflicts
  • Visualize commit histories
  • Search repository histories for changes

See it in Action

Link to youtube video:

Wave in a Box

I don't know if anyone else got as excited about Google Wave as I did a couple of years ago before Google canned it.....probably not because I was REALLY excited, as in couldn't sleep the next night so excited because I thought it was going to change everything. If they had been less stingy with invites I think it would have really caught fire, but they probably had good reason for doing so, but that's another story.

I just spent a few minutes firing it up from the Apache "Wave in a Box" project - amazingly it works!

I just followed the instructions found here and about 2 minutes later (plus a few for checkout and building) it was up:

So if you're missing Wave as I am you can feel empowered once again.