I can't stand second best

Whenever I find a technology that I really like, theres almost always something similar-but-different that comes along and claims to do X or Y better, and all my friends are checking it out. Sometimes its better and I move straight into it. The strange thing I've noticed though, is that in virtually all other cases I wind up hating this newcomer with a fiery passion.

The first victim was Python. I liked Ruby first, but python was (and is) what all the cool kids were doing. As I began using it, I was mostly happy with it. I mean sure, using an indent as a token with syntactical meaning would seem to imply that you'd want a single fixed way to express an indent (and therefore, tabs not space). And sure, typing len(foo) instead of foo.len() was a sin against OO warranting excommunication, but hey, who likes a purist? And hey, would I really care that lambda was so bad if I hadn't been using Ruby? I suppose having so many methods on the standard objects be in-place was a bit difficult to deal with, and not being able to add new methods to the base classes was unfortunate, and not having a good lambda mechanism meant I couldn't use map/reduce as effectively as I wanted, which was pretty much out of the question anyway since they used function calling semantics rather than being a method, but that meant I couldn't do complex transformations on information as a single series of method calls on the previous result, which would screw up half the time anyway because the operations were in-place, and now... wait a minute, I hate Python!

Now, Python is doing very well for itself, and is gradually eating away at Java's ill-gotten turf, and I welcome all of this. I can tolerate the existence of Python. I don't mind it being around or being used, I don't dread having to dig into it to fix a problem I have, but I don't particularly enjoy it. Its not bad, its just not right. Personal preference? Maybe, but it does show what happens when I try to look at the more popular cousin of something I already found the merits of.

The latest victim was bzr. I am a git user, but I have to work with bzr in order to contribute to Upstart's upstream on Launchpad. It was rocky from the start. Bzr's "a directory is a branch, not a branch container" mantra, which most bzr users are exceptionally proud of, always rubbed me the wrong way. This is a preference issue. I wasn't too upset by it. It just meant that local branching was no longer a part of my daily workflow. I adapted. The next bump I ran into was lack of a rebase feature. This was the bigger culture shock. Bzr doesn't believe in keeping history "clean." I don't quite understand the philosophy, but they seem very near to proclaiming that the shape and ordering of the history is an implementation detail. There doesn't seem to be much emphasis on the "what if I need to look/go back there" use case. Why would the user care what's in the repository anyway?

The final straw was in an attempt to remedy this flaw. There's a project to create a rebase plugin for bzr, and on a friend's suggestion I checked it out. This was the beginning of the end. Rebasing took forever. The plugin was ungodly slow, and this was the first time in dealing with bzr that I really was bothered by the performance. Bzr does bench slower than git/hg, but I consistently found it to be "fast enough." I didn't find myself going to get a coffee while bzr crunched things until this. Despite the slowness, though, it did appear to set my tree in order, so I went ahead and pushed to Launchpad... which failed. It failed because my two branches now appeared to be divergent. In order to push, I'd first have to merge in my outdated upstream branch that consisted entirely of changes that were already in what I was pushing. Well fine. I guess that's an easy enough issue to have, particularly when I just did an unsupported operation. I'll just set things an order and... and thats when I realized I was fucked.

Bzr does not have cherry pick. It does not have interactive rebase. There were ways to pull the changes out of my working tree, but no way to rearrange the history to be a strict superset of my upstream. The operation seemed so trivial, and yet it was impossible. Suddenly it was all so clear to me. The "advanced features" that bzr admitted to lacking and claimed it was just as well off without weren't advanced at all. They were the whole point! Git's history manipulation was the reason I used it. All bzr does is track your changes. Git actually lets you manage them.

Two days later I had the opportunity to play with interactive rebase for the first time. I was able to squash a pair of commits several down from the head with no difficulty whatsoever. I went straight off and asked a git developer if there was a git-bzr plugin. He provided me with a rough copy of one that wasn't quite ready for heavy lifting, but its coming. I won't be sad to be rid of bzr. Its usefulness is now all but lost on me.