Fork me on GitHub

home

A few handy git aliases

May 16, 2013 | *nix, Computers | 1 comment

I finally got fed up with some repetitive Git tasks and decided to make a few aliases in my .gitconfig file. Here are the commands, they all assume that they’re run from a valid git repo:

Push your current branch to your upstream repository

How often do you repeat the git command to push your current branch by typing git push origin [current-branch-name] because you never remember to set up the branch to track? Does this sound easier?

$ git pb

Alternately, here, you can add a default push method to your .gitconfig:

[push]
default = current

So that you can just call git push to and have git automatically assume you typed git push origin [branch-name]

Pull just the current branches updates

With larger groups of developers it is easy for a git pull to fetch a lot of new refs that you don’t care about. This alias shortcuts git pull origin [current-branch-name].

$ git up

A quick and easy update of just what you care about. Save big the git pull for lunch time or a coffee break.

Open the current branch on GitHub

We use GitHub Enterprise at work and going to look at the current branch/repo on the server is pretty common. So to make it super quick to get where you want to go this command will open up the GitHub server to the current repo and branch that you’re on. This works with self-hosted GitHub FI/Enterprise installs as well as public GitHub.

$ git gh

Open up GitHub to a new Pull Request

As a part of using GitHub Enterprise at work we’ve heavily adopted Pull Requests as the primary method of requesting code reviews and for pulling approved code in to master. However constantly finding the branch or manipulating browser history becomes tiresome. So this alias opens up GitHub to ‘/owner/repoName/pulls/new/current-branch-name‘ so that you can fill in a detailed pull request (you are filling out a pull request with a description and testing plan, right?).

$ git pr

Git log graph on the Cli

I don’t now about you, but I’ve not been able to get on board with the dedicated git apps for browsing and visualizing history trees, but once in a while I do want to look at the tree but don’t want to load an app to do it when a simple view on the cli will do.

$ git lg

Ok, enough jabber, gimme the code

Ok, its pretty straight forward. Just add this to your .gitconfig:

[alias]
lg = log --graph --pretty=format:'%Cred%h%Creset %C(yellow)%an%d%Creset %s %Cgreen(%cr)%Creset' --date=relative
pb = "!git push origin \"$(git rev-parse --abbrev-ref HEAD)\""
up = "!git pull origin \"$(git rev-parse --abbrev-ref HEAD)\""
pr = "!open \"$(git remote -v | grep origin | grep push | cut -f 2 | cut -d \" \" -f 1 | sed -e \"s|git@\\(.*\\):\\(.*\\).git|https://\\1/\\2|\")/pull/new/$(git rev-parse --abbrev-ref HEAD)\""
gh = "!open \"$(git remote -v | grep origin | grep push | cut -f 2 | cut -d \" \" -f 1 | sed -e \"s|git@\\(.*\\):\\(.*\\).git|https://\\1/\\2|\")/tree/$(git rev-parse --abbrev-ref HEAD)\""

Are those ugly? Sure. Do they help? Yep!

I’m sure as time goes on I’ll figure out a few more. Or maybe the three of you that actually read this far have suggestions? Lemme know.

Operation Shave the Wookiee, the Return

January 27, 2013 | Life | 5 comments

shave-the-wookiee-the-return

Here we go again.

St. Baldricks is 2 months away and I’m in once more. Its been 2 years since I last pitched in and I’ve got 12″ of hair waiting to be shaved.

On my head, you pervert.

Last time was a success. After all was said and done and last minute donations tallied I managed to raise a little over $1200. Thanks to everyone who donated. It was much more than I was expecting.

And here I am. Ready to go again. On March 30, 2013, at the Children’s Hospital & Research Center in Oakland, California, I’ll once again sacrifice a full head of hair in the interest of raising some dough for a good cause.

Give me, er, the kids, money!

Or join Team Wookiee. I’d be thrilled to have teammates. I’ll need someone to celebrate with since my wife has already made it clear that I’ll be sleeping in the other room until at least some hair grows back. However, I’ve just been informed that if I raise at least $2,000 that she’ll actually sleep with me while the hair grows back.

Art at Stanford

January 24, 2013 | Life, Photography | No comments

Sequence 2

The wife and I decided to take a trip down to Stanford last weekend to check out the Rodin Garden at the Cantor Arts Center on the Stanford campus.

Now, I know that I went to a small school. My graduating class was measured in the hundreds. But, holy shit, the Stanford campus is huge and beautiful. Granted we saw most of it while trundling to and from the Cantor Center, but that was enough to show off how great a campus it is. And to have such a large, and free, museum on campus to boot just makes me feel like I need to outright take my parents to task for not having the ability to send me to a much better school than the rug-rat fest that I attended.

;) Kidding. Mom, Dad, love you.

So, while we went to primarily check out the Rodin garden something else stole the show for both of us. Well, besides the campus, that is. And that was the sculpture/installation by Richard Serra named Sequence. The installation was designed to walk through. With wonderfully textured and rust-colored ~10′ high walls it quickly engulfs you and lets you hide away in a small world that only consists of the gray floor, the red walls, and the blue sky. It was quite wonderful. Mr. Serra, if you’re reading this, I’d like one for my back yard. Can I get one about one fifth the size of that? Great! Thank you!

Sequence Sequence 3

I love you too, Stanford…

A Winters Day at the Beach with the Fuji X-E1

January 9, 2013 | Photography | 1 comment

DSCF0544.jpg

The wife and I decided to take the mutts for a walk on the beach this past weekend. We expected cold and dreary weather but were pleasantly greeted by partly cloudy skies and quite warm temperatures when the sun was out. All in all a good day to play with the new Fuji X-E1. In case you’re about to bolt, weary of more shots of my dogs, please venture forth, they’re not the feature of this post ;) Fair warning, though, I had every intention of going out and shooting for black and white images, so there’s very little color in these photos.

(more…)

MacPorts, Homebrew and Mountain Lion

July 26, 2012 | *nix, Computers | 8 comments

The inevitable happened today. Mountain Lion was installed in a couple of different places. Unfortunately one of those places was at work and on a development machine before we had a chance to test out Mountain Lion compatability. Predictably, issues arose. Not surprisingly, at least to me, Homebrew has the biggest issue, and an issue based on its core philosophy.

But first…

XCode

Prior to Mountain Lion the Xcode Command Line Tools could be downloaded separately from Xcode. This saved many of us the bandwidth and storage space required to install Xcode. As of the time of this writing I can only find the individually downloadable Command Line tools available for regular old Lion.

So that means a download of Xcode is required. Dag nabbit.

After downloading and installing Xcode open Xcode and go in to its Preferences, click on the Downloads tab and install the Command Line Tools.

Update: As noted by Patrick Quinn-Graham in the comments below, the Command Line Tools are now showing up in Apple’s Developer portal. I recommend grabbing that if you don’t need the full Xcode suite.

After that is done head to the command line and accept the command line tools usage agreement.

$ sudo xcodebuild -license

Press space a few times to get through the whole thing and then type “accept” when it prompts you to. This provided a fun distraction for both Homebrew and MacPorts as the errors delivered because of needing to accept the usage agreement in no way point to the root cause of the errors. And to add insult to injury this was not needed on every system that I’ve had to manage. I found this by blind luck.

We’re done with Xcode. We’re now ready to compile applications on Mountain Lion.

MacPorts

MacPorts survived the upgrade just fine. MySQL, PHP and Apache were all running when Mountain Lion restarted. But just to be safe I updated MacPorts.

$ sudo port selfupdate

After the update almost everything that I had installed became listed as “outdated”. So, everything needed upgrading… :sigh:

$ sudo port -cup upgrade outdated

But, all in all, done and done. Ok, eventually it was done after 6 hours of compiling.

Homebrew

Homebrew was harder. Homebrew’s base philosophy, a philosophy that everyone loves about it (well, except for me) is that it uses already installed system libraries to run. Today that proved to be a bad thing.

Apple removed support for X11 in Mountain Lion. This means that anything that was linking to a library that was supplied by X11 would now complain and die. This meant our custom compiled version of PHP at work. dylibs were missing which prevented PHP from running and header files could not be found which prevented an update to PHP from compiling.

The Homebrew folks saw it coming a while back. There are pull requests and changes in branches that deal with this issue. However the best I can tell not all of that has made it in to master and its still not ready to go.

There is a work around, and it relies on installing XQuartz to provide the required X11 libraries. This may not be required for everyone, but for those of us that run specific versions of software it means a headache. In our case, for PHP, it meant that libraries required for font and image handling were missing. And these are just the errors that came up first. I’m not sure how many other things that X11 provided were waiting to error out should we have tried to link in the parts as we found the errors.

First, download and install XQuartz. After doing that symlink it in to where Homebrew expects X11 to be. We had folder there, presumably left over from the upgrade.

$ cd /usr
$ mv X11 X11.bak
$ ln -s /opt/X11 X11

Now, since this was an OS upgrade all of the config and ini files have been renamed and replaced. This means that the Apache conf and PHP ini files needed replacing. Fortunately for us we had a custom Homebrew Formula that handled this portion of the environment for us. So we just had to uninstall and reinstall that Formula to re-configure Apache and PHP how we had it. Your setup will of course be different.

Conclusion

So, overall, while my total time spent troublehsooting, updating and fixing a Homebrew install today took up a little more than 4 hours of my day, it was fixed and working.

While I’m still pissed at Homebrew for taking more of my brainpower today its 4 hour investment is a bit shorter than the time it took MacPorts to get up to date.

I have to say, though, that despite the longer compile time to update MacPorts I still prefer it for the sheer fact that it didn’t force me to pay attention to it to upgrade to ML. I decided to pay attention to it (and would have had to eventually anyway). I was able to address MacPorts on my time, not because something was horribly broken.