Update, 27 July 2010: git 1.7.2 released earlier this week, has support for passing a range of commits to git cherry-pick. See the release notes. For my pre-1.7.2 solution, read on.

• Sandy pointed to a Federico blog post which formats the commit range as patches, changes branches, and re-applies them. @lyager also recommended this method.
• Federico himself suggested using rebase --onto.
• Garrett and Havoc recommended just merging the branch and then rebasing out the commits I didn’t want.
• Garrett also suggested gitk --all.
• On IRC, Peter suggested combining git rev-list and cherry-pick.

All fine suggestions. I wanted something that I could easily transform into an alias since I’ve been doing this a lot lately, and I’d like it to scale to large numbers of commits. I ended up going with Peter’s suggestion, and behold! I present to you:

git apple-pick¹

or, as a git alias:

apple-pick = !sh -c 'git rev-list --reverse "$@" | xargs -n1 git cherry-pick' -

Given a range of commits, it cherry picks them onto the current branch. The workflow:

$ git checkout my-branch
... hackety hack, do a bunch of commits ...
$ git checkout master
$ git apple-pick abc123^..my-branch
Finished one cherry-pick.
[master abc123] tweak some junk
1 files changed, 9 insertions(+), 0 deletions(-)
Finished one cherry-pick.
[master def456] did some awesome stuff
6 files changed, 30 insertions(+), 22 deletions(-)
Finished one cherry-pick.


Thanks for the help guys, and I hope you gitinistas out there find it useful. What other cool alises have you developed or found that help your daily workflow? Tweet them to me.

¹ Federico thinks I should call it git transplant instead. He’s probably right, but mine’s cuter.

Right now inbound/outbound markers are not working due to a change in the MBTA’s feed. It’s not clear if this was intentional or a bug, and I’m not the only one who is having issues with it.

I have a Canon HF200 HD video camera, which records to AVCHD format. AVCHD is H.264 encoded video and AC-3 encoded audio in a MPEG-2 Transport Stream (m2ts, mts) container. This format is not supported by Aperture 3, which I use to store my video.

With Blizzard‘s help, I figured out an ffmpeg command-line to convert to H.264 encoded video and AAC encoded audio in an MPEG-4 (mp4) container. This is supported by Aperture 3 and other Quicktime apps.

$ ffmpeg -sameq -ab 256k -i input-file.m2ts -s hd1080 output-file.mp4 -acodec aac

Command-line order is important, which is infuriating. If you move the -s or -ab arguments, they may not work. Add -deinterlace if the source videos are interlaced, which mine were originally until I turned it off. The only downside to this is that it generates huge output files, on the order of 4-5x greater than the input file.

Update, 28 April 2010: Alexander Wauck emailed me to say that re-encoding the video isn’t necessary, and that the existing H.264 video could be moved from the m2ts container to the mp4 container with a command-line like this:

$ ffmpeg -i input-file.m2ts -ab 256k -vcodec copy -acodec aac output-file.mp4

And he’s right… as long as you don’t need to deinterlace the video. With the whatever-random-ffmpeg-trunk checkout I have, adding -deinterlace to the command-line segfaults. I actually had tried -vcodec copy early in my experiments but abandoned it after I found that it didn’t deinterlace. I had forgotten to try it again after I moved past my older interlaced videos. Thanks Alex!

I decided to hack together a mashup of this data with Google Maps, to see how easy it would be. In the end it took me a few hours on Saturday to get the site up and running, and a couple more on Sunday adding features like the drawing of routes on the map, colorizing markers for inbound vs. outbound buses, and adding reverse geocoding of the buses themselves.

To do this I used three technologies (Google App Engine, JQuery, Google Maps) and two data sources (the real-time XML feed and the MBTA Google Transit Feed Specification files).

Google App Engine

App Engine is so perfectly suited for smaller, playtime hacks like this that it’s hard to imagine how anyone got anything done before it existed. The tedious, up-front bootstrapping that is required in so many programming projects has been enough to completely turn me off to small, spare-time hacking projects on occasion in the past. The brilliance behind a hosted software environment is obvious, but the amount of work to build a safe, hosted system with a fairly comprehensive set of APIs seems to be such a mountain of work that in many ways I find it surprising that anyone — even, perhaps especially, Google — built it at all.

I chose the Python SDK and the programming was straightforward and easy. It takes some elements from Django, with which I am familiar from work.

JQuery

A no-brainer. Hands down the best JavaScript toolkit available. Making the AJAX calls to get route and vehicle location information was a breeze, and the transparent handling of the XML data of the real-time feed prevents me from losing the will to live — a common feeling when dealing with XML.

My only complaint is with the documentation. While the API reference is good for any given piece of the API, the examples are a little light and there is absolutely zero cross-referencing to other parts, especially ones not a part of JQuery itself. It was not obvious, for example, how to deal with the XML document returned by the AJAX call. It sounds like the docs are getting some work, though, so this will hopefully improve.

Google Maps

This was my first endeavor with the Maps API, and it’s good. It’s not the best API in the world, but it’s hardly the worst either. Adding markers of different colors is annoying, but not so onerous as to make it tedious. The breadth of functionality provided is impressive, but then again it has been around for a few years at this point. Markers are easy to add, drawing the route map is absolutely trivial with a KML file, and even the reverse geocoding — which gives you a street address given a latitude/longitude pair — is straightforward.

The docs suck, though. There’s no indication that a size or anchor position is required when creating an icon for a custom marker — required for colors other than red — and due to the minified JS files tracking down that error took longer than any other task in the project. Reverse geocoding mentions that a Placemark object will be returned, but that class doesn’t appear anywhere in the reference documentation.

Real-time feed data

Lots to like. Straightforward, easy to parse. It’d be nice if I didn’t have to do the reverse geocoding to figure out what the street address is, but it’s not a dealbreaker. Main downside is that it’s XML as opposed to JSON. And of course, it’s only 5 bus routes and zero subway and commuter rail routes.

MBTA Google Transit Feed Specification files

A comprehensive set of data describing every transit route, every stop, and every route in the MBTA system. An impressive set of data encoded in a format designed for Google Transit. There is a set of example tools to view and manipulate this data, and one of those translates this data into a KML file for use with Google Maps. I should have tweaked the tools to output only the KML for the routes I cared about, but I did this by hand instead… not a big deal for only 5 bus lines. These KML files are fed into the Google Maps API to display the route as a blue line on the map when selected.

POKE 47196, 201

This is what a lot of programming is like now, for better and for worse.

On the one hand it is the perfect example of high-level component-oriented programming. Data is formatted in easily parseable interchange formats and plugged into well-defined interfaces. These interfaces plug into other interfaces. The result is a zoomable, pannable map with real-time bus location information that updates every 15 seconds. The lines-of-code count is around 100 including both Python and JavaScript. With a few hours work, I built something modestly useful out of nothing. I stand on the shoulders of giants.

On the other hand I didn’t really build anything. This is just assembly line programming. It was not a particularly creative endeavor, and it wasn’t challenging intellectually. Anybody could have done it. It’s cool, but there is little sense of accomplishment in the end product. It feels a little hollow.

Which is not to say that I didn’t enjoy it, or that it wasn’t worth the effort. I learned new technology, I played with software and data that I hadn’t had the opportunity to before. I broadened my horizons, however slightly. And it got me to write this blog post.

Connect your iPod to the Mac, and turn on hard drive access in iTunes if it’s not already on.

You’ll need your music or podcast to be in AAC (.m4a) format. If you have an MP3, go into iTunes preferences -> General -> Import Settings… and set the “Import using” encoder to AAC. Then select the tracks and go to Advanced -> Create AAC Version.

Copy the new .m4a file into the Recordings directory on the iPod, and give it a name like “20090101 120000.m4a”.

Eject your iPod and go to the voice memos feature. In your list of voice memos you should see something like “1/1/2009 12:00 PM” — it corresponds to the filename above — and press play. Voilà!

It’s not an elegant solution, but it’ll give you something new to listen to on your subway ride home when you’re desperate.

The frustrating thing is that Apple already has the One True User Interface for playing audio: the click-wheel. With its handling of acceleration you can both seek through hours of audio extremely quickly while still giving you the one-second resolution to seek to the exact point you want, and I don’t understand why it isn’t emulated on the iPhone and iPod touch. At this point, I have to believe that there is some limitation of the touchscreen hardware which prevents it. Sigh.

The previous day Brette, my mom and I were joking around that the baby would almost certainly come the following day — still a few days before his due date — during the snowstorm that was expected to drop up to 15 inches of snow on Boston. He didn’t disappoint. We found ourselves walking to the birth center about half a mile away in the 4 or 5 inches that had fallen at that point on nearly deserted roads during Friday rush hour, stopping briefly whenever Brette had a contraction.

The birth went amazingly well and I am so proud of Brette. All of the nurses and midwives at the birth center were talking about what a wonderful job she did, and I couldn’t agree more.

A few things I wanted to mention:

If you prefer to give birth in a hospital, or want a pre-scheduled c-section, go for it. Do whatever is most comfortable and appropriate for you. But Brette and I wanted a natural childbirth without surgical intervention unless medically necessary, and for us the Cambridge Birth Center was the perfect place. Situated inside an old Victorian house, it sits across the street from the Cambridge Hospital. The rooms are homey and comforting. The only thing that annoyed us was the constant snow plowing going on just outside our window… but once things got down to business we weren’t paying attention to any of that. The nurses and midwives were so wonderful and accommodating. We were allowed to walk around, bring whatever food we wanted with us, got to sleep after the birth and go home the following afternoon. Just a great experience.

Ok, this is important: get a doula. I think I was as helpful and comforting as I could be for Brette, but look, I don’t have a uterus. I never have and probably never will. But a doula does. I don’t know physically what it’s like to give birth. A doula very well may have gone through it herself. But most importantly, they have training on ways to make the laboring woman more comfortable, and her entire job is to support and comfort. Ours was fantastic, and I can’t imagine going through the birth without her.

Also many thanks to my mom, who has been with us for the past week. She has helped us tremendously with keeping the house clean and orderly, making us food all the time, giving us a relief when we’ve been overwhelmed with E. at all hours, and sharing her experience with us.

Merry Christmas.