In his excellent introduction to Magit, Mickey Petersen does a great job of explaining basics of Magit workflow. If you haven’t heard of Magit, it is a fantastic frontend to the Git DVCS, written on top of the Emacs environment. The entry point to Magit, which is magit-status, is not bound to any key by default, so after switching to Git and Magit, I bound it to (previously undefined) C-x g. But when I was reading Mickey’s article, one thing struck me. Mickey says that
If you’re a user of Emacs VC then you must know that, frustratingly, Magit makes no effort to integrate itself into Emacs’s VC (Version Control) abstraction layer.
That’s right – and it’s a pity. Since before using Git I used Mercurial a lot (and I still do), and even earlier I used RCS (yes, I know, I know; but in fact, for single-user, single-directory and often single-file LaTeX projects, RCS does its job just fine), I did use Emacs’ VC a lot. And now, with Magit, C-x v v is useless for me in Git repos. I don’t want to rebind it to magit-status, since I have a lot of Hg repos I still use, and I need vc-next-action for them, I put this in my init.el:
(defun magit-status-or-vc-next-action (arg)
(interactive "P")
(if (eq (vc-deduce-backend) 'Git)
(magit-status default-directory)
(vc-next-action arg)))
(global-set-key "\C-xvv" 'magit-status-or-vc-next-action)
Of course, I lose the possibility of using magit-status with prefix arguments with this simple setup, but it’s not a problem for me; for switching between projects, I’m fine with C-x C-f (and Ido), and for setting up a new repo, M-! git init is good enough for me. So now I have a single entry point to both VCs I use.
Of course, this is rather simplistic. And maybe it’s not that good idea, to; maybe it would be better to use Emacs’ VC for simple Git/Hg actions, and use e.g. C-x g for magit-status or monky-status depending on the VC used (I have yet to try Monky). I’ll try different things, and time will tell.