Garbled

So I use this great thing called OtherInbox. They’re in closed beta just now, but if you follow them on Twitter you’re likely to see when they hand out another round of invites (which they recently tweeted would be coming early in January, if I remember right). Let me tell you a bit about OI before I go into my rant. Hopefully it will segue nicely.

OtherInbox is an email, uh… application. Like Gmail or Hotmail, sort of. When you sign up for OI, though, you don’t get _username_@otherinbox.com, you get a whole subdomain and infinite email addresses at it. So, _whateveryouwant_@_username_.otherinbox.com. Then, when you login to your account, you’re presented with folders based on the email address that the email came to. It’s sort of like filters in other email clients, except you don’t have to set them up, you just hand out a new email address. So if I sign up for a new site, I hand it _sitename_@_username_.otherinbox.com and when they send me email, it automatically goes to a folder in my OI named after that site. So I have an Amazon folder and a Twitter folder, etc. etc.

You can also have a vanity URL and edit your MX records on the host so that email gets routed to OI’s servers, so that you don’t have to use the long _username_.otherinbox.com in your emails. So I have benhamill.com set up that way. Very, very nice feature, that.

Okay, so why might you want this service? Well, spam, firstly. If I’ve only ever given a certain email address away to amazon.com and I start getting spam to that address, I know who the culprit is. Also, if I want to sign up for something that I expect to get spam from, I can do so without fear. After getting that confirmation email, I can just hit the “Block All” button and OI will just not show me those messages. I don’t have to worry about it ever again.

Another use case which I’m loving is when you sign up for what’s called bacn; stuff you want, but not, you know, right now. I use OI to sign up for email lists and such that I don’t want cluttering up my inbox. Stuff I might want to read, but over the weekend or whatever; stuff that’s not time-sensitive.

Which leads me to my rant. If you’re not an OtherInbox user, the following might not make a lot of sense, so you might want to skip it until you are. And I highly recommend you become one. I found that the more I used it, the more I liked it. So, rant on…

OtherInbox is not your primary inbox. It’s right there in the name. I was confused about this at first, too, but it should be obvious. You don’t ditch gmail for OI. You use them both. How you divide it up is something people do differently, but here’s my rule of thumb: If it is sent by a computer (as opposed to a human), it goes to OI. What this does (ideally, since I haven’t finished converting all my accounts over to OI addresses) is makes it such that the only emails that show up in my gmail account are ones that are actually to me.

I mean–how many emails do you get from computers? If you’re like me then a lot. I get email every time someone follows me on Twitter and every time someone sends me a message in my online Diplomacy game and every month when Rock Band sends out their “zine”. Why not have a computer help me deal with it all? It’s not going to read it for me, of course, but it _will_ help me process them. If I know I ordered something from Amazon, then I will look at new emails to my amazon address when they show up. Otherwise, I’ll probably ignore it.

However, OI is pretty bad at displaying conversations. I mean–that’s not a fault, that’s not part of their core mission. They’ve been talking about adding a feature like that since it makes sense for mailing lists, but for personal email, gmail is still king. Tags and search and conversation view, etc. That’s what gmail is good at. OI is good at sorting spam and bacn.

People who talk about having their friends each email an OI address based on their name just confuse me. Your friends aren’t going to sell your email address to spammers or send you stuff you don’t want to read (or, if they are, get new friends… elderly relatives, on the other hand, who will send you random jokes might warrant an OI address), so there’s no need to hide you *real* email address. If you want, you can set up auto-forwarding for an OI address, but just hand that out to real people like you would your real address.

It can get sort of heady, making up any old address to give to people, but if you’re handing out OI addresses to real people, you’re sort of defeating the purpose of OtherInbox. Either you’re using OI’s interface, which is optimized for dealing with emails en mass, or you’re having to set up a bunch of auto-forwards to your primary inbox (with the nice interface for dealing with individual emails). OI is supposed to make it so you don’t have to set up filters or auto-forwards all the time.

I really love OtherInbox. If you’re not a user (and you didn’t skip the rant), really go follow them on Twitter and get an invite code. Or find someone who’s in the beta now and see if they have any invites left (I have a single one as of this writing). I didn’t think I was really an awesome candidate for an OI user, but that’s only because I didn’t realize how much email I get from computers. It’s really freeing to be able to click “Yes, send me updates” on everything. If you never get anything from them that’s worth your time, you never waste any time on it. Throwing away that email address it completely trivial. The real trick to having OtherInbox improve your life is not swimming against the stream, though. So remember my rant when you sign up.

I’ve recently started using git to version control my personal projects. I’ve also recently started using GitHub for hosting remote repos of that stuff. So I’m new to it all and I might be wrong, here. But, having read a few articles here and there and talked to some other people (most notably, another git newbie @carl_youngblood), aren’t cherry picking and rebasing really, really horrible things to do to a repo? Even if it’s just your local one? They destroy history, which is sort of the point of version control, no?

I’ve seen, in the last few days, two articles on GitHub that make me wonder which of us (me or GitHub) doesn’t get it. My inclination is to assume it’s me who’s missing something. If so, I’d love for someone to tell me exactly where I’ve missed a step.

The first article I want to talk about is the Fork Queue announcement. It’s basically a tool that makes it really easy to see which of the people that’ve forked your project have pushed commits you don’t have in your repo and then to cherry pick them in. You can pick your branch, etc. This is to keep you from having to create a lot of remotes, I guess. It’s supposed to “[allow] you to do a email patch style workflow without actually having to deal with patches over email”. I thought that part of the point was that that work-flow was a pain? I also feel like it’s missing the part where the person making the patch tells you about it, rather than you going and getting it from them. A pull-request is much more like that.

I don’t know… I sort of feel like we should be putting roadblocks in the way of cherry picking; make it harder for people to adopt work-flows where cherry-picking is common. My understanding (and again let me stress that this may be incorrect) is that the best work-flow is for the patcher to fetch your code (because it represents some kind of “core” or “official” release, yes?), merge it into a new branch, make his(her, etc.) changes, test them, fetch your code again to make sure he has the latest, perhaps retest, then issue a pull request. When you’re acting on the pull request, you fetch his stuff down to a new branch, test, possibly merge in any changes you’ve made to master since he issued the pull request, then _merge_ into master. This preserves all the history. It’s all fetches and merges.

So the other article is the Changing Git History article. This one is about going and messing with old commits. I’ll try not to rant as much on this one. I’m not as adamant, but I do find it kind of silly, this idea of making a commit a perfect little gem. I can see fixing a typo in the commit you just made, so git commit --amend doesn’t seem so bad. However, the git rebase -i portion after that… bleh. I realize this isn’t a GitHub feature like the above; it’s a part of Git, but I wonder why. If the commits were that horrible, revert them all and do it over. If they weren’t that bad, just live with the typo. No? Even if you haven’t pushed it, rebasing just seem icky and to be avoided, especially if it’s just to fix commit messages.

Okay… So, maybe I’m out of line or off base or insane. It’s entirely possible. Some would say probable. It wouldn’t surprise me if I’ve failed in some very basic way to understand the Git philosophy. It also might be that I’ve misunderstood what GitHub’s written and that the clash between these articles and Git philosophy is all imagined by me. I’m open to these possible realities. Correct me or soliloquize or slam me in the comments, if you like. I am all ears… or eyes. Whatever.

Update: Before anyone gets the wrong idea, here… I’ve been loving using git and GitHub. They’re both spectacular. Without them, I wouldn’t have found enki for use in powering this blog. This post is about trying to understand something confusing in something great; I’m not trying to imply that either should be done away with or that I could do better. I just wanted to head off the most major take-it-the-wrong-way that occurred to me on the way in this morning.

I’m mostly posting this to document it to myself, since I always forget, but it might be helpful to any readers, as well. You generally don’t want to be logging in to your computer as a user with admin privileges and a sane OS (like Mac OS or Linux), makes it a fairly painless experience. Windows, on the other hand, can be a real bear on the point. Specifically, Windows Explorer doesn’t like to do the whole “Run as…” thing. I’ve discovered a wonderful little run line that will solve this problem.

In the run line (Windows key, then R or click Start menu then Run…) put in runas /u:administrator "explorer.exe /separate". You’ll want to replace administrator with an appropriate user name if that’s not a valid one. A DOS prompt will appear asking for the password and away you go. This tip thanks to Stack Overflow.

I also found something else handy here: You can input run-line commands into the “location” prompt when creating a shortcut from scratch in Windows. So if you don’t want to type out all that /u:administrator stuff all day (or, well, probably not that frequently and you’d forget it), then you can right-click > New > shortcut and paste your command into the location. Call it whatever you want and then you’ve got a shortcut to an admin Windows Explorer right on your desktop.

I find this so much easier to deal with than any other solution when I need to muck with file permissions or any number of things in Windows. Helpful? Didn’t work for you? Thoughts on the site design? Let me know in the comments.

Well, I finally got this thing working. Don’t book mark it yet, I plan on changing the URL over, but have to deal with registration transfer, etc. and don’t feel like mucking with that yet. Please, if you like, comment on the aesthetics or if you notice anything doesn’t work.

I’ve got the source code for this blog up on GitHub, which you can check out if you like. I’m sure people will say that I’ve got some stuff in source control that I shouldn’t. If you post something like that in the comments, I’ll at least have a look at it and consider. Deploying’s a pain if you leave important stuff out of version control, no?