I realized today that I was a bit behind the times:
john@jeebus ~
$ git --version
git version 1.5.5
The latest release is 1.5.6.1. Time to update git.
Rather than downloading a tarball, I figured it would make more sense to use git to get the latest git. Seems like the natural thing to do. Back when I first installed, I had cloned the git repo just to see what was going on. So, I cd‘d into my local git repo and pulled all new updates (my commands are in bold):
john@jeebus ~
$ cd src/vendor/git
john@jeebus ~/src/vendor/git (master)
$ git pull
remote: Counting objects: 6351, done.
remote: Compressing objects: 100% (3760/3760), done.
remote: Total 5830 (delta 4322), reused 2995 (delta 2036)
Receiving objects: 100% (5830/5830), 2.71 MiB | 656 KiB/s, done.
Resolving deltas: 100% (4322/4322), completed with 401 local objects
...snip...
From git://git.kernel.org/pub/scm/git/git
* [new tag] v1.5.6.1 -> v1.5.6.1
Updating 189d6b8..d54467b
...Lots more updates snipped...
Ah hah, I see that the 1.5.6.1 release has been tagged. Sweet, that’s what I want. So, I’ll check out that tag:
john@jeebus ~ '/src/vendor/git (master)
$ git checkout v1.5.6.1
Note: moving to "v1.5.6.1" which isnt 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 e636106... GIT 1.5.6.1
john@jeebus ~/src/vendor/git (v1.5.6.1)
$
Good, now I’ve got the code that was tagged as v1.5.6.1 checked out into my working directory.
(You may have noticed that I’ve got my bash prompt displaying which branch/tag that is currently checked out. This is incredibly handy, and probably worth its own separate post, so I’ll save it for later.)
I like to install all my stuff into /usr/local, so I’ll run the configure script with the —prefix option to tell git where it should go.
john@jeebus ~/src/vendor/git (v1.5.6.1)
$ ./configure --prefix=/usr/local
-bash: ./configure: No such file or directory
Uh, wha? No configure script? What the crap is this? Turns out, after RTFM, the configure script has to be generated first with make. Ah, I see.
john@jeebus ~/src/vendor/git (v1.5.6.1)
$ make configure
GEN configure
john@jeebus ~/src/vendor/git (v1.5.6.1)
$ ./configure --prefix=/usr/local
configure: CHECKS for programs
checking for cc... cc
...snipped all the configure output...
Next, make the dang thing.
john@jeebus ~/src/vendor/git (v1.5.6.1)
$ make
GIT_VERSION = 1.5.6.1
* new build flags or prefix
CC daemon.o
CC alias.o
CC alloc.o
CC archive.o
...snippity snip...
And finally install (as sudo).
john@jeebus ~/src/vendor/git (v1.5.6.1)
$ sudo make install
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Nothing to be done for `all'.
SUBDIR perl
SUBDIR templates
install -d -m 755 '/usr/local/bin'
install -d -m 755 '/usr/local/bin'
...more snips...
Done! I’m rollin’ with the latest git release!
john@jeebus ~/src/vendor/git (v1.5.6.1)
$ cd ~
john@jeebus ~
$ which git
/usr/local/bin/git
john@jeebus ~
$ git --version
git version 1.5.6.1
Note: these steps don’t seem to install the updated git man pages, as they’re still on 1.5.5. I’m working on figuring that one out. But for now, I’m happy to have the latest git, and can google for the docs when I need them. :-)
Updates: Aug 28, 2008
- It’s probably a good idea to run
make clean before doing subsequent updates. That’ll clear out all the cruft from the old version before building the new one.
- As of git v1.5.something, the “dash” style
git-[cmd] commands are depreciated. I’ve updated the commands above to use the non-dash style.
- Also, I discovered a one-line command to install the man pages.