Domain of the Bored

In another tussle with Git, I performed the following sequence of commands:

1. cd mach_star-rentzsch
2. git fetch (from GitHub)
3. cd ../mach_star-boredzo
4. git fetch rentzsch (in this context, my git-remote alias for ../mach_star-rentzsch)
5. git merge rentzsch/master

Step 5 failed with “Already up-to-date”.

What? I just fetched! I should have new commits to merge in!

Nope. For one thing, this output from step 4:

From ../mach_star-rentzsch
 * [new branch]      master     -> rentzsch/master

seems to mean “OK, here's a new name for the master branch of that other repository, but we didn't actually bring in any commits”.

The reason it didn't bring in any commits is because git fetch apparently only fetches commits that are ancestors of the source repository's current HEAD. In English: git fetch cares what you have checked out in the source repository.

It's because I had fetched in step 2, and thereby not changed my HEAD, that step 4 did not see anything new to fetch. I don't know why it works that way, or why they consider it useful.

Anyway, the “correct” sequence of steps is not much different: git pull, not fetch, in step 2 above. Or use Mercurial, which I've found makes a lot more sense in general.

It's entirely possible that I've figured this out the wrong way, so take this entire explanation with a grain of salt.

Just in time for tomorrow's release of Snow Leopard, TimeMachineGrowler is an app that will tell you how long Time Machine takes to create a back-up by posting Growl notifications when the back-up starts and finishes.

One of the promised “refinements” in Snow Leopard is faster back-ups, so you may find it interesting to compare how long a back-up takes on your machine running Leopard to how long it takes on Snow Leopard (assuming, of course, that you haven't already abandoned Leopard for the Snow Leopard GM).

Here's an idea I just had. No idea how you could monetize it, except perhaps by a subscription fee, but let's not worry about that just yet.

It's a combination of a file-storage service and music-streaming service. You would upload your own music so that you could listen to it from anywhere: Mac, Windows, maybe Linux OSs, maybe the iPhone. You can't make your uploads public; you have to log in with client software or in a web browser. On a desktop machine, it could make like iTunes and play the local copies of music instead of streaming, especially if the network is down.

The service would uniquify songs*, so when you upload your copies of the songs, it will certainly associate the song with your account, but when you stream it, it may serve you someone else's copy instead of the one you uploaded—higher bitrate wins, and more/better tags break ties. Not only would this help keep the storage costs down, but everybody who uses the service would basically get a free bitrate upgrade on a song any time someone uploaded a higher-bitrate version of it. (It would probably be a good idea for the service to keep one of every bitrate so that users can set a maximum.)

But here's the real twist. Suppose that there were an alternate entrance through which musicians could upload their own music for everybody to have. If an artist or label wants to give away a song for free, they can flip a switch and everybody has the song. Of course, any listener can remove the song from their account if they don't want it. Perhaps the artist (or their label) could see how many people have done that.

So imagine this. Starting from your desktop Mac, you upload all of your music to the service. Then, when you go on a trip, you bring your laptop and/or iPhone and can use one or both to listen to the music you uploaded. And, over time, your music collection grows with no effort from you as musicians post free songs for everybody.

What do you think?

*No, I have no idea how to do that. Title, artist, and album are not sufficient. ↶

Before:

if (![newTrackURL isEqualToString:trackURL] || ([newTrackURL hasPrefix:@"http://"] && !([lastPostedDescription isEqualToString:displayString]))) { // this is different from previous notification, or it's a stream and the playing track has changed

After:

BOOL URLChanged = ![trackURL isEqualToString:newTrackURL];
BOOL isStream = [newTrackURL hasPrefix:@"http://"];
BOOL descriptionChanged = ![lastPostedDescription isEqualToString:displayString];
if (URLChanged || (isStream && descriptionChanged)) {

Why remove the comment? Well, I had just changed the code to what you see in the Before example, but I had not changed the comment, and I thought I was ready to commit. I almost committed a stale comment. It's that easy. Luckily, I caught it in reading the patch before I qfinished it, so I was able to change the comment to what you see above.

Now I have no comment at all, but the code is clear, so I don't need one. This is an improvement.

UPDATE 2009-08-14: Or just use CopyPath, which looks like a much better implementation of exactly the same thing. Thanks to David Keegan, its author, for suggesting it in the comments.

The original post content follows.

This is a script application, which apparently you can drag into your Finder toolbar. (If it doesn't let you, you didn't drop it in the right spot. Finder is finicky about this. Keep trying.)

Once you've added it to your toolbar, you can just click on it to run it. The script will copy the UNIX path of whatever you have selected in Finder to the clipboard.

Inspired by a conversation with Alan Boyd.

In Portal, Testchamber 13:

Despite the best efforts of the Enrichment Center staff to ensure safe performance of all authorized activities, you have managed to ensnare yourself permanently in this room.
A complimentary escape hatch will open in Three… Two… One.