Emacs and Magit

LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

The Git source-code management system is widely known for its flexibility and for the distributed development model that it supports. Its reputation for ease of use is ... less well established. There should, thus, be an opening for front-end systems that can make Git easier to use. One of the most comprehensive Git front ends, Magit , works within the Emacs editor and has a wide following. But Magit has run into some turbulence within the Emacs development community that is blocking its wider distribution.

A look at Magit

Magit is an Emacs-Lisp (elisp) program, available from the MELPA package archive or directly from GitHub. While the web site does not directly address pronunciation, the usage found there suggests that it sounds more like "magic" than "maggot". Which is probably a good thing.

Once Magit has been installed on a user's system and hooked into Emacs, a magit-status command will bring up a window (in Emacs terminology — a "pane within the window" to many others) that is the primary control mechanism. It shows the information available from a " git status " command and can be used to directly look at the uncommitted changes found within the repository. The tab key can be used to expand or hide various subsections of this window.

Many Git operations are just a keystroke or two away when one is in this window. Position to a changed file and hit " s " to stage a change, or " u " to unstage it. Individual hunks can also be staged or unstaged if desired. Typing " c " brings up the commit options; another " c " will bring up a window for the commit message. From there, " ^C^C " will finalize the commit. The " p " command can be used to push to another repository.

There is, of course, a set of options for examining the commit stream; many of them produce an ASCII-art version of the merge history shown by tools like gitk . Many of the common Git logging options (limiting to a specific author or searching for a given string) are available. The log display can be enhanced with diffstat information or the actual patch content. Magit can work with the reflog as well as with the regular commit stream.

The blame mode is another useful way to examine a file's history. When first started, it will annotate a source file with a set of headers indicating which commit added each line, along with author, date, and subject-line info. The actual commits are a keystroke away. Running magit-blame recursively goes to the version of the file just prior to when the lines under point were added. When a commit of interest is found, " M-w " puts the appropriate hash into the kill ring for easy access later.

Naturally, there is support for merging that can use either Smerge or ediff; the latter is, in your editor's opinion, one of the nicer Emacs features in general. Ediff can also be invoked to examine the difference between any two revisions of a file. There is support for rebasing, including handy commands for quickly editing a commit in the history and rebasing the branch on top of the result. For simple tasks like, for example, adding an "Acked-by" to a commit, Magit is far easier and quicker than using git rebase directly.

Most other common Git operations — managing remotes, branching, tagging, cherry-picking, stashing, generating pull requests, etc. are supported. There is special mode for bisecting. If the good-or-bad test can be scripted, then the entire bisection process can be run automatically by Magit. All told, it does appear to be a comprehensive interface to the Git functionality needed by most users.

Whether one sees Magit as a better way to use Git will depend, naturally, on one's attitude toward Emacs-based interfaces in general. It is all keyboard-based, of course, as befits a text editor; there is a pulldown menu if Emacs is running within its own window(s), but most users probably don't invoke it often. The vast number of operations and options provided goes well beyond what most users can be expected to remember — that is to be expected, since Git itself is like that. To get around this problem, Magit uses a series of "popups" displaying the available keystrokes. The experience is somewhat similar to working with the WordStar word processor, for the old-timers out there.

There are some complaints to be made about the system, even if the highly modal interface sits well. If a Git command puts out a strange error message (not an unusual occurrence with Git), Magit tends to throw up its hands and say "go look in that other buffer for the error message". Some operations can take a long time — measured in minutes for some logging commands your editor tried — and there is no visual indication that Magit is working or what progress it is making. A lot of (seemingly) irrelevant messages about reverted buffers and such show up in the message line when operations are proceeding. It's not a perfect or seamless interface, by any means.

Including Magit in Emacs

The Emacs editor ships with a wide array of add-on packages, but Magit is not one of them. That was the topic of a recent discussion on the Emacs development list where, to the dismay of some participants, Richard Stallman expressed a wish that "someone would write a package comparable to Magit" that could be included in Emacs. That would seem like a strange wish: Magit appears to be the best Emacs interface to Git, providing functionality that a lot of Emacs users wish to have. It is licensed under GPLv3. It is a large package with an active development community, not something that could be quickly replaced at anything resembling the current level of functionality.

So why is Stallman calling for a project to compete with an established and free Emacs package? The answer, of course, is that Magit contains the work of a long list of developers, quite a few of whom have not filed paperwork assigning their copyrights to the Free Software Foundation. The FSF still insists on such paperwork, refusing, in most cases, to take on software that it cannot claim ownership to.

This sort of discussion comes up occasionally on the Emacs list, with the same result every time. In this case, John Yates said that Magit "could emerge as one of those oh-so-elusive creatures: a true killer app for the emacs platform". He added that "sometimes community might be more important than copyright assignment" and asked Stallman to reconsider. Stefan Monnier, who has seen many such discussions, limited himself to saying:

If we want to distribute something like Magit with Emacs, there's no need to write a replacement: we can simply include Magit itself, since the license allows us to do so. The only hurdle is the one *we* (Emacs maintainers) put.

Stallman, however, is not known for being swayed by such arguments; his response in this case made it clear that he was not going to change his position. Either all of the significant contributors to Magit must sign papers with the FSF (with code from the holdouts being replaced), or an entirely new Emacs interface to Git must be written.

Phillip Lord has announced that he will make an attempt to get the papers for Magit in order. Only time will tell if he will succeed. Either way, though, a lot of work will be expended to either enable the distribution of software that is already distributable, or to try to replace it with equivalent functionality. It is hard to see this as a win for Emacs users or developers, and it would not appear to be a winning strategy for Emacs in general.

