11 March 2008 2:23 PM (version control | emacs | git | bzr)
So I'm a big fan of these new distributed version control systems. For most of my personal projects I use bzr, which works fine and doesn't tax the brain too much. At work (awesome web site) we use git, which I have grown quite fond of.
These systems, while distinct, do share obvious similarities. They're all distributed and more or less fast, they all eschew changelogs, they all do tree-wide atomic commits. So the obvious question I know that you have on your mind is, "Isn't there a rocking emacs mode that can support all of these things?"
OK if not, you should probably stop reading. Otherwise, DVC is your answer. It's super. Here's how to get it:
cd ~/src bzr get http://bzr.xsteve.at/dvc/ cd dvc autoreconf -vif mkdir ++build/ cd ++build/ ../configure make
Then add this to your .emacs:
(add-to-list 'load-path "~/src/dvc/++build/lisp") (require 'dvc-autoloads)
Then restart emacs (or C-x C-e after each of the closing parentheses), and open some file that's in git (or bzr, or monotone, ...). Edit something, save, and type M-x dvc-diff. You get a list of files that changed, followed by diffs. You can use j to jump back and forth between the file list and the diffs, n and p to navigate between diffs, or C-c C-c to go to the file in question.
Most excellently, pressing t will open a new buffer for the commit log, with a nicely-formatted log entry (similar to C-x 4 a), which you can edit, save, kill, whatever -- the next time you press t in the dvc-diff buffer, you'll have that same log message to edit. Until the point at which you want to commit, at which time you might want to press g in the dvc-diff buffer to refresh the diff, then C-c C-c in the log buffer to actually commit the change.
The nice thing is that all of this works regardless of the VC system that you're using. Each system also has some extra methods you might be interested in (e.g. xgit-apply-mbox), but more or less you can treat them the same.
As an aside, I think people that like git do so out of a kind of software Stockholm syndrome: you have to learn so much about esoterics like refs, the object database, the index, etc. that you end up feeling empathy for git's idiosyncracies. Because objectively, git's working tree index should not be a concept that occupies space in my mind.