How to make the most current version of git available on macOS

macOS and Xcode are always a few releases behind the currently available version of git. There are just a few simple things you need to do in order to rectify this inequity. If you are reading this then you are probably already familiar with the git CLI commands, but just to be sure:

  • check the version of git
ewilson$ git version
git version 2.9.3 (Apple Git-75)
  • check to see where git is being executed from
ewilson$ which git
/usr/bin/git

If your system looks like this then you'll need to modify your .bash_profile (if you run bash - or modify the profile file for your corresponding shell). Since I am going to use homebrew for the new git install I need to make sure the path of the new executable (brew installs in /usr/local/bin) comes before the macOS version which is typically located in /usr/bin. Thusly:

export PATH=/usr/local/bin:$PATH

Now all that's left is to install git and you are golden

ewilson$ brew install git
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> New Formulae
metricbeat
==> Updated Formulae
...

==> Downloading https://homebrew.bintray.com/bottles/git-2.10.2.sierra.bottle.1.tar.
######################################################################## 100.0%
==> Pouring git-2.10.2.sierra.bottle.1.tar.gz
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d

zsh completion has been installed to:
/usr/local/share/zsh/site-functions

Emacs Lisp files have been installed to:
/usr/local/share/emacs/site-lisp/git
==> Summary
🍺/usr/local/Cellar/git/2.10.2: 1,445 files, 31.8M

Now when you run git version you should see the latest and greatest

ewilson$ git version
git version 2.10.2

Awesome. To keep things up to date all you'll need to do is run brew upgrade

brew upgrade git

Don't forget to update any tools or IDEs that you may have been using to make sure that they now point at your shiny new version of git.

Git, Fabric and Python - Tag You're It

There are many discussions that you can read about value of creating 'versions' or 'versioning' software.  More often then not, the versions (e.g. v 1.2.34) are used for marketing purposes or commercial product releases.  Does the internal engineering staff pay attention to such monikers on a daily basis?  Not really.  

There are some instances, however, whereby knowing exactly which files on running on what server can come in handy.  

I wrote this Fabric task that can be called when doing a code push.  It tags the set of files with the name of the host machine the deploy is going to + a unique time stamp.  It also creates a 'tag' file which contains what branch of the code was used for this deployment.