My recent series of posts in which I had some difficulty with GIT (1, 2, 3) have garnered a lot of interest, and generated some discussion.  Many of the replies saw the funny side, which is nice as I was hoping to be at least amusing (rants are, after all, a form of entertainment) and more than I expected sympathised.  Many tried to help by giving me a sequence of commands that might work, ironically often the exact same commands I used in my original post.

And many told me I was an idiot, and that they had no problem; and that I should learn how to use GIT instead of just stabbing at guesses.

Those made me realise what the fundamental difference between myself and them are.

I don’t want to use a revision control system.

It follows that if I don’t want to use one, I certainly don’t want to waste time learning one!  I don’t want to use a text editor either, again it’s just something that gets in the way of what I really want to do.

I want to write code, and I want to fix bugs and test the fixes.

Actually, I don’t really want to fix bugs; but it’s one of those things you have to do as a responsible software author and maintainer.  Now, I sadly can’t just write code by thinking about it.  Even though I use zsh, holding down the TAB key just doesn’t write my code for me, so I have to use a text editor.

And I hate them, especially emacs, which is the text editor I use.  I keep hoping that one day Anjuta or something like MonoDevelop will be usable for writing and debugging C – but alas, that day has not yet come.  (Incidentally, if a developer would like some constructive criticism from my side, I would be perfectly happy to do give it – just grab me on IRC).

Now I don’t have to use a Revision Control System, unlike a text editor which is somewhat essential, but there are a lot of advantages to using one.  In particular, I think I have two primary use cases:

1. Keeping a history of my changes
2. Sharing my work with others, and allowing others to share their work with me.

Since I don’t want to use a Revision Control System, it should be as simple and painless to use as possible.  I have probably a dozen common actions that I do; so each of these actions should be just one command, with no options or flags to make them do the right thing.  For bonus points, these commands should be obvious and ideally have aliases for the similar commands in other systems for easier learning.

Here’s the first set:

• get a copy of some source code, to which I can make my own changes if I wish
• save my current set of changes to the history
• put a copy of my source code, with changes, somewhere others can get at it
• update my source code with changes made to where I got it from

We could probably call these get, commit, push and pull. Note that I’m not allowing for any kind of add, move or remove command.  Such things are a pain in the neck; my most common preference is just for any changes I’ve made to be committed.  This is probably one big reason why GIT and I don’t get on so well; it’s written for somebody else’s use case where the most common use case is committing nothing.

Since I pretend to like other people working on my software, I’ll need a couple of commands for doing that:

• review the changes somebody else’s source code makes to mine
• add the changes they’ve made to my source code.

I’ve yet to see a revision control system that makes the first one easy, which is sad, because it’s just about the most common operation I do on other people’s branches/repositories/clones; I’d call that review, and then we can call the second one merge.

And then for the last set:

• look at the history of changes
• examine the difference between two versions
• extract a single change, in a format compatible with mailing

We can call these log, diff and show (though ideally diff and show would be just the same command with a revision range or single revision).

I’ve probably forgotten something important, but in general, those are the operations I try and do with a revision control system.  Thus I can create a Revision Control System Hate Index.  The more commands, options or flags it takes to do any of these operations, the higher the Hate Index and the more I’ll loathe it.

GIT scores badly, very few of these operations are a simple command.  Many require pre-configuration, many require options and flags to do the right thing.  And a couple of them are actually multiple commands.

In fact, GIT’s hate index gets increased further, because after a while you realise that most of the top-level commands very rarely do the right thing.  Instead, you start to break down the commands to their fundamentals.  If you’ve ever found yourself using git fetch you know what I mean.

This means that I have to stop thinking about writing code, and start thinking about using the revision control system and what the best way to accomplish the operation that I want is.  This is a fail that only results in hate.

And just for the peanut gallery, I’d like to point out that Bzr has a non-zero Hate Index as well.  In fact, there are misfeatures and bugs in Bzr that make my blood boil just as much as GIT, sometimes even more since Bzr actually claims to always try to do what I mean.

You know what would make me happiest?  If I had a text editor that took care of revision control for me.  Sometimes I wish there was a Linux version of the good old Borland IDE or at least VisualStudio.