Development

Using Emacs and Git with Magit 2.1

There is more than one way to mesh a Git workflow with the Emacs editor. As we saw in April, one option is the VC module for Emacs, which provides a common wrapper around many version-control systems. Some Emacs users, however, feel that the one-size-fits-all approach of VC can shortchange the version-control system in question—particularly when the system is Git. As a result, the dedicated Git-integration tool Magit has a loyal following in Emacs circles. The project is preparing to release version 2.1, a major update, so I decided to take a look.

The Magit team is scheduled to push out version 2.1 on "July 1th" (although, as of press time, the release has not yet occurred). The update will mark a major milestone; the previous release series was the 1.4 branch. Maintainer Jonas Bernoulli noted in the release schedule that using a .1 minor number may be confusing to some but that it is the same approach taken by Emacs (the next major release of which will be version 25.1).

Stable Magit releases can be downloaded and installed within Emacs using the built-in package system, if one adds the MELPA repository first. MELPA is a third-party repository that packages many more add-ons than the official, default package repository ELPA. Nevertheless, it has earned a reputation for stability and reliability over the years, and poses little risk of destabilizing one's system.

The 2.1 release of Magit should make its way to MELPA in relatively short order; in the meantime, it can be downloaded and installed from GitHub (using the "next" branch). The only significant dependency is on dash.el, which is also available through MELPA.

Welcome to the Magit kingdom

For those (like myself) who are new to Magit, the most significant feature of the package is that it provides an almost toolbar-like interface to Git's major features—coupled with a smart "dashboard" for tracking and exploring the status of one's code. This dashboard is an interactive Emacs buffer that, by default, takes up a small portion of the Emacs window. When the user opens a file in a Git repository, the buffer shows the current head and upstream branch, with the most recent commit listed for each.

As the user edits files, the status buffer updates to track staged and unstaged changes, untracked files, stashes, and more. Staging a change is as simple as moving the cursor over it in the "unstaged" list and hitting "s" (and unstaging a change can be done with "u"). Although by default, the staged and unstaged sections list files, hitting "TAB" opens a diff of the file, with insertions and deletions highlighted in green and pink, respectively. In this mode, the "s" and "u" keys can be used to stage or unstage individual hunks.

Typing "c" performs a commit, which triggers a small pop-up buffer to accept the user's commit message. A "p" initiates a push, while "l" opens up the current branch's log. The log is another interactive buffer: the user can navigate back to an earlier commit within the log and select it to perform any of several actions—such as rebasing or squashing. Typing "b" brings up the branch buffer, from which the user can create, delete, or checkout branches.

The majority of the time, users are likely to stick to this relatively small subset of Git's functionality, but Magit also provides interactive tools for bisecting bugs, displaying a blame, and performing more complex repository manipulations (like merging or cherry-picking).

There might be a lot to say just about the benefits of Magit's context-aware pop-ups. No matter what the situation, typing "h" pops up a cheat sheet of the available commands. That can be helpful for anyone who has yet to develop an instinctive grasp of all of Git's options. Similarly, the interactive commands (such as commit) pop up a buffer containing a list of the available options, each of which can be clicked with the mouse as if it was a button. But that buffer accepts keyboard input, too, which allows those users who prefer to work fast to simply keep typing.

But the more subtle benefits of Magit are how smoothly it integrates Git functionality with the normal Emacs editing environment. All of the normal Emacs navigation and editing commands work as they usually do, and a great deal of work has clearly gone into binding Git actions to Emacs hooks that can be called by Magit in the background as one works.

That is to say, Magit is far more than a series of pop-ups allowing one to enter an external Git command. Rather, Magit does "the right thing" behind the scenes as one works. To provide one simple example, users can highlight multiple files in the status buffer and stage or unstage them all at once. This is what an Emacs user would expect, since selecting text between the point and the mark works this way for general editing. If Magit simply displayed a list of files, without tracking the point and mark, such a feature would likely not work.

The 2.1 release

According to the release notes for 2.1, much of the work that went into this new Magit release was behind the scenes: implementing performance improvements and increasing consistency within the internal abstractions. Nevertheless, users who are familiar with Magit 1.4 will find a lot to like in the new release, too.

The biggest change is the addition of a new library named with-editor.el. This is a library that allows Git to call an Emacs client process whenever it needs an editor. Magit 2.1 uses this functionality internally for interacting with Git during rebases and commits, but it has another benefit, too. It allows Magit to connect to remote machines using the Emacs TRAMP (Transparent Remote (file) Access, Multiple Protocol) package.

Magit 2.1 also features a completely rewritten blame tool. The new implementation is interactive: the user can jump to the next (or previous) chunk belonging to the same commit, see the revision history for the chunk at the cursor point, and much more. For experienced Git users, there is now a preference to disable Magit's confirmation questions for "dangerous" commands. There are also new functions to insert cherry-picked commits, preview merges, and locate the commits that cause a merge conflict.

Several existing Magit features have had important bug fixes in this release. For example, in version 1.4.x, it was possible to create a snapshot or stash of the current state, including both staged and unstaged changes, but it was not possible to stash or snapshot just the staged changes. Now that limitation has been removed. Similarly, there had been some inconsistencies in earlier releases, wherein not every "git apply" variant (i.e., stage, unstage, discard, reverse, and "regular apply") would work on all of the possible content types (a single file, multiple files, hunks, etc.). Now all of the "apply" functions behave consistently.

The under-the-hood changes to Magit 2.1 pave the way for more substantial improvements in subsequent releases. A significant number of functions have been renamed so that they group into sensible categories by function-name prefix. Several utility libraries have been reorganized or combined, and a few removed in favor of existing Emacs libraries like dash.el.

The upshot of all of this refactoring work is that Bernoulli says he is now gearing up to work on some long-requested new features, like integration with code-hosting platforms and code-review utilities. He hopes to launch a fundraising drive to finance further work.

For someone (like myself) who uses Emacs yet rarely pushes Git to its limits, Magit definitely offers its advantages. It is certainly superior to jumping over to a terminal emulator and stepping through a series of Git commands. Users with more demanding Git workflows will probably find Magit 2.1 more to their liking (if they found the 1.4 series limiting), and it sounds like there is quite a bit more work still to come from the project.

Comments (12 posted)

Quotes of the week

— Tollef Fog Heen

— Zack Weinberg dissects the project-management issues in Google's recent kerfluffle over hidden binary extensions in Chromium.

Comments (6 posted)

Ardour 4.1 released

Version 4.1 of the Ardour digital audio workstation software has been released. There are some new features in the release including input gain control, support for capture-only and playback-only devices, a real "Save As" option (with the old option being renamed to "Snapshot (& switch to new version)"), and allowing plugins to be reordered and meter positions to change without adding a click into the audio. There are also lots of user interface changes, including better High-DPI support. "This release contains several new features, both internally and in the user interface, and a slew of bug fixes worthy of your attention. Encouragingly, we also have one of our longest ever contributor lists for this release. We had hoped to be on a roughly monthly release cycle after the release of 4.0, but collaborations with other organizations delayed 4.1 by nearly a month."

Comments (none posted)

Amazon's new TLS implementation

Amazon has announced the release of a new TLS library called "s2n" under the Apache license. "s2n is a library that has been designed to be small, fast, with simplicity as a priority. s2n avoids implementing rarely used options and extensions, and today is just more than 6,000 lines of code. As a result of this, we’ve found that it is easier to review s2n; we have already completed three external security evaluations and penetration tests on s2n, a practice we will be continuing."

Comments (31 posted)

Erlang/OTP 18 is available

Version 18.0 of Erlang/OTP has been released. This version incorporates several major changes, such as a new time-handling API, bug-fix updates to SSL support, a new Hash Array Mapped Trie (HAMT) representation for large maps, and a number of scalability and performance improvements. On a non-technical front, 18.0 is the first release to be made available under the Apache 2.0 license, dispensing with old Erlang Public License (EPL) used in previous releases.

Comments (none posted)

GnuPG 2.1.6 released

Version 2.1.6 from the GnuPG "modern" branch has been released. This update fixes a number of bugs, as well as adding a --verify option for the gpg-agent PASSWD command, an offline option for gpgsm, and fixes to locale support and the management of LDAP helper processes.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (June 29)
• LLVM Weekly (June 29)
• OCaml Weekly News (June 30)
• OpenStack Community Weekly Newsletter (June 26)
• Perl Weekly (June 29)
• PostgreSQL Weekly News (June 28)
• Python Weekly (June 25)
• The R Journal (June)
• Ruby Weekly (June 25)
• This Week in Rust (June 29)
• Wikimedia Tech News (June 29)

Comments (none posted)

Graham: Django's Roadmap

At the Django project blog, Tim Graham announces that the Django team has decided to adopt a new release schedule, "following over 3,000 responses to the Django Developers Community Survey and a long discussion on the django-developers mailing list". The next release, version 1.9, is slated for December 2015, with subsequent releases to follow every eight months. The April 2017 release, Django 1.11, will be designated a long-term support (LTS) release. Subsequent LTS releases will follow every two years.

Comments (none posted)

Linux Foundation Announces R Consortium

The Linux Foundation has announced the R Consortium. "The R language is used by statisticians, analysts and data scientists to unlock value from data. It is a free and open source programming language for statistical computing and provides an interactive environment for data analysis, modeling and visualization. The R Consortium will complement the work of the R Foundation, a nonprofit organization based in Austria that maintains the language. The R Consortium will focus on user outreach and other projects designed to assist the R user and developer communities. Founding companies and organizations of the R Consortium include The R Foundation, Platinum members Microsoft and RStudio; Gold member TIBCO Software Inc.; and Silver members Alteryx, Google, HP, Mango Solutions, Ketchum Trading and Oracle."

Comments (none posted)