Stories from the land of Rob

Now as anyone who knows me knows, I love Git. I find it gives a very productive and comfortable workflow. One of my favourite new(ish) features is git rebase --interactive, which along with cheap’n'fast branching gives a great way to hack and commit as you go and then later on refactor your work into sets of nice orthogonal patches.

However, there I do still find a good few things wrong with git, so I’d like to discuss these problems and possible solutions:

1. Error Messages

   In general git has some terrible cryptic error messages. My favourite example is if you modify a file and then pull a change that modifies that file before you commit it:

   Updating beb8c37..b953e6f
test: needs update
fatal: Entry 'test' not uptodate. Cannot merge.

   WTF? what does uptodate mean? why isn’t it up to date? whats gone wrong? what should i do?
   Surely something like:

   Cancelling pull as 'test' has changes that would be overwritten by this pull. Please commit your changes or force an overwrite using the '--force' flag

   would be a lot better?

   I leave it as a reader excercise to repeat this process for most error messages…

2. The index

   Why oh why oh why is it called the index? It does no indexing as far as the user is concerned. Its name gives you no clue to what it is, you don’t know when or how you’re supposed to use it. git add and git rm modify it and it’s used all over the place by the obscure low-level git helpers that you stumble over.

   How about commit staging area, that being what it actually is. You could have nice commands like git stage and git unstage and git stage --interactive. That’d make more sense, right? Then git add and git rm would be a lot more meaningful, being only used when you actually want add or remove a file.

3. Remotes

   With git remote this is a lot better than it used to be - having to use cryptic refspecs (see git-pull manpage for the gory details). Unfortunately refspecs are still scattered all over the documentation just to confuse you… That should almost certainly be moved out to less user-visible documentation.

   The main issues I have now are:

   • Remote branches don’t always behave like local branches when they should. In particular git pull . <remote branch name> doesn’t work (and gives an obscure error) but git merge <remote branch name> does. remote branches should act just like local branches you can’t modify.
   • I’m not sure I like git branch -r to list remote branches, maybe git remote branches would be nicer and more obvious, or even git branch --remote
4. Lots of git-* commands that confuse people

   This is a common complaint, and I have to say that I agree. Why not put all the low-level commands in libexec? People who really use them often (which can’t be many!) can always add it to their path.

5. No bug tracker!

   For such a user-facing tool, a bug tracker would be very useful for users who lack the experience or time to get their hands dirty in the codebase. It certainly seems that just taking bugs to the mailinglist without a patch isn’t generally useful.

So, what do people think? What other bugbears do beginners and experienced git users see? Are these useful ideas?

After some discussion, I’ll happily take these to the git mailing list and come up with some patches!

Update:
Looks like people had some problems with my OpenID based login. Comments are now open.

The Mozilla Foundation is funding Codethink to investigate the feasibility of moving the GNOME accessibilty infrastructure, AT-SPI, to use D-Bus as its underlying IPC rather than CORBA.

You can follow the investigation as it progresses on the GNOME Wiki

Hopefully our findings will show that D-Bus is more than up for the job, paving the way to a true cross desktop accessibility infrastructure!