iphone eve
Walk in to the office today, and on the whiteboard, scrawled in giant letters, I see:
Happy iPhone Eve!
Truth. Happy iPhone ev-ery-body.
Now, the only question that remains… Black or White?
Walk in to the office today, and on the whiteboard, scrawled in giant letters, I see:
Happy iPhone Eve!
Truth. Happy iPhone ev-ery-body.
Now, the only question that remains… Black or White?
Don’t know why I didn’t do this before. The hot new thing is to put your dotfiles up on GitHub. Now it’s trivially easy to keep my terminal life in sync across my macs.
Here’s the link to my terminal bliss.
I forked Ryan Bates’ project, since he’s got a nice rake task to install symlinks for each of the files, and I liked his file structure. I’ve added some svn aliases, more git shortcuts, and updated the git completion script to the latest version. Also changed the bash prompt to show me what’s checked out when my current directory is a git repo. Here I’m in the master branch of my dotfiles project:
john@jeebus ~/src/dotfiles (master)
$
Very handy.
So, getting a new mac tweaked to my liking is only three commands away.
john@jeebus ~/src $ git clone -o github git@github.com:johnreilly/dotfiles.git Initialize dotfiles/.git Initialized empty Git repository in /Volumes/Speedy/src/dotfiles/.git/ remote: Counting objects: 168, done. remote: Compressing objects: 100% (80/80), done. remote: Total 168 (delta 84), reused 163 (delta 79) Receiving objects: 100% (168/168), 25.02 KiB, done. Resolving deltas: 100% (84/84), done. john@jeebus ~/src $ cd dotfiles john@jeebus ~/src/dotfiles (master) $ rake install (in /Volumes/Speedy/src/dotfiles) linking ~/.bash linking ~/.bash_profile linking ~/.gemrc linking ~/.gitconfig linking ~/.gitignore linking ~/.irbrc linking ~/.railsrc
Loving it.
In a previous post, I was confused on how to install the latest git man pages after updating my git installation. Turns out to be a single command!
$ git archive origin/man | sudo tar -x -C /usr/local/share/man
Pretty awesome. The git maintainers made this very easy, as they’ve got a ‘man’ branch that contains the latest auto-generated man pages. A simple copy-through-tar technique gets it all installed.
This makes a couple assumptions:
Hot times. I’m now sportin’ git v1.5.6.2, plus the associated docs.
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. :-)
make clean before doing subsequent updates. That’ll clear out all the cruft from the old version before building the new one.git-[cmd] commands are depreciated. I’ve updated the commands above to use the non-dash style.