Comments (1)

By Adam, October 5, 2014 1:59 pm

Like many F/OSS developers, I’m a heavy user of GitHub. This means I interact with other developers via GitHub multiple times a day. GitHub has a very nice notifications system which lets me know when there has been some activity on a project I’m collaborating on.

I’m a fan of David Allen’s GTD (“Getting Things Done”) system, and in my experience I get the best results by minimising the number of inboxes I have to look at every day. So I use another great feature of GitHub, which is the ability to have notification emails delivered directly to your email inbox. This means I don’t have to keep checking https://github.com/notifications in addition to my email inbox.

However, this means that I receive GitHub notifications in two places. Wouldn’t it be nice if when I read them in my email inbox, GitHub could somehow realise and mark them read at https://github.com/notifications too, so that when I look there, I don’t end up getting reminded about notifications I’ve already seen in my inbox? Happily the folks at GitHub already thought of this too, and come up with a solution:

If you read a notification email, it’ll automatically be marked as read in the Notifications section. An invisible image is embedded in each mail message to enable this, which means that you must allow viewing images from notifications@github.com in order for this feature to work.

– https://help.github.com/articles/configuring-notification-emails/#shared-read-state

But there’s a catch! Like many Linux geeks, I use mutt for reading and writing email. In fact, I’ve been using it since 1997 and I’m still waiting for another MUA to appear which is more powerful and lets me crunch through email faster. However mutt is primarily text-based, which means by default it doesn’t download images when displaying HTML-based email. Of course, it can. But do I want it to automatically open a new tab in my browser every time I encounter an HTML attachment? No! That would slow me down horribly. Even launching a terminal-based HTML viewer such as w3m or links or lynx would be too slow.

So I figured out a better solution. mutt has a nice message-hook feature where you can configure it to automatically execute mutt functions for any message matching specific criteria just before it displays the message. So we can use that to pipe the whole email to a script whenever a message is being read for the first time:

message-hook "(~N|~O) ~f notifications@github.com" "push '<pipe-message>read-github-notification\n'"

(~N|~O) matches mails which have the N flag (meaning new unread email) or O (meaning old unread email) set.

The read-github-notifications script reads the email on STDIN, extracts the URL of the 1-pixel read notification beacon <img> embedded in the HTML attachment, and sends an HTTP request for that image, so that github knows the notification has been read.

This means an extra delay of 0.5 seconds or so when viewing a notification email, but for me it’s a worthwhile sacrifice.

If you want to try it, simply download the script and stick it somewhere on your $PATH, and then add the above line to your ~/.muttrc file.

UPDATE 2017/08/29: Unfortunately I have since discovered that the above solution breaks when you try to save one of these notifications before reading it. Suggestions on how to fix this are most welcome!

Comments (2)

By Adam, November 6, 2013 7:05 pm

Facebook goes some way towards making it easy for you to invite groups of friends to an event, but it still requires a mouse click for each person you want to invite. If you have a friend list containing more than a handful of people, this rapidly gets tedious. Don’t worry though! Here’s a way to select the whole list in one go.

Continue reading 'How to invite groups of friends to a Facebook event'»

Comments (2)

By Adam, October 2, 2013 2:05 pm

I recently blogged about some tools I wrote which harness the notes feature of git to help with the process of porting commits from one branch to another. Since then I’ve discovered a couple more consumers of this functionality which are pretty interesting: palaver, and Gerrit.

Continue reading 'more uses for git notes, and hidden treasures in Gerrit'»

Comments (15)

By Adam, September 19, 2013 9:22 pm

Have you ever needed to port a selection of commits from one git branch to another, but without doing a full merge? This is a common challenge, e.g.

• forward-porting / upstreaming bugfixes from a stable release branch to a development branch, or
• back-porting features from a development branch to a stable release branch.

Of course, git already goes quite some way to making this possible:

• git cherry-pick can port individual commits, or even a range of commits (since git 1.7.2) from anywhere, into the current branch.
• git cherry can compare a branch with its upstream branch and find which commits have been upstreamed and which haven’t. This command is particularly clever because, thanks to git patch-id, it can correctly spot when a commit has been upstreamed, even when the upstreaming process resulted in changes to the commit message, line numbers, or whitespace.
• git rebase --onto can transplant a contiguous series of commits onto another branch.

Comments (6)

By Adam, August 23, 2013 7:00 pm

I’ve been a bit of a hermit the last few weeks, burning the candle both ends and spending the majority of my spare time building a new toy … well actually it started out as a toy, but now I think it’s good enough for musicians to use as a serious tool for improving their improvisation / compositional skills, and harmonic understanding.

So I’m very pleased (and relieved) to be able to announce … <drum roll> … the Scale Matcher!  It should work equally well on your computer, phone, and tablet.  Please try it out and let me know what you think!  You can also click the About and FAQ buttons to find out more.

Thanks to Barak Schmool for providing the original inspiration to do this, and for the time he spent testing it out and suggesting improvements.