E macsAir

Collecting frequent-committer miles

Magit 2.90 released

I am excited to announce the release of Magit version 2.90, consisting of 395 commits since the last feature release five month ago. The release notes can be found here.

It’s Magit! A Git interface inside Emacs

Magit is a text-based Git user interface that puts an unmatched focus on streamlining workflows. Commands are invoked using short mnemonic key sequences that take the cursor’s position in the highly actionable interface into account to provide context-sensitive behavior.

With Magit you can do nearly everything that you can do when using Git on the command-line, but at greater speed and while taking advantage of advanced features that previously seemed too daunting to use on a daily basis. Many users will find that by using Magit they can become more effective Git user.

For more information about Magit, see https://magit.vc and these blog posts.

Breaking changes

There are other breaking changes beside those mentioned here. See the release notes.

Last release to support Emacs 25 and Git 2.0

As announced earlier older Emacs and Git versions won’t be supported much longer. This is the last Magit release to support Emacs 25 and Git 2.0, i.e. this release drops support for Emacs 24.4 and Git 1.9. Soon Emacs 26.1 is going to be required. Support for older Git releases will also be dropped but it isn’t certain yet when that will happen and what the new minimal version will be.

Renamed many commands

Many commands were renamed, making their names longer. The old names are defined as aliases for now. This is part one of a two part change. In this release we rename, for example, magit-tag to magit-tag-create and in a later release magit-tag-popup is going to be renamed to magit-tag.

Improvements to work-in-progress refs

A new mode magit-wip-mode was added, which enables automatic committing to work-in-progress refs whenever that makes sense.

Previously multiple magit-wip-* modes had to be enabled to accomplish the same. These modes still exist (the new mode is even implemented on top of them) but their explicit use by the user is discouraged now.

Originally I also planned to change how the wip refs are updated by default when a new commit is created on the current branch, but for now the new behavior has to be opted in using the new option magit-wip-merge-branch.

By default the wip refs are reset to point at the same commit as the current branch after a new commit is created on the current branch. When you set magit-wip-merge-branch to a non-nil value, then the current branch is instead merged into the wip refs.

The newly added approach should make it easier to reason about how the wip refs relate to their branches, but that is only partially true, which is why it isn’t the default yet. If the user rewrites history a lot, e.g. by repeatedly amending, then the commit graph can get really complicated. Also merging the real branch into the wip refs instead of resetting the latter means that wip commits are never garbage collected. Both complications make additional tooling necessary before the new approach can become the default.

Two new commands magit-wip-log-index and magit-wip-log-worktree were added.

Specifying the major-mode used for commit messages

It is now possible to specify the major-mode used to edit commit messages on a per-repository basis. The same major-mode is also used to prettify commit messages when displaying existing commit messages in magit-revision-mode buffers.

To set the major-mode to be used for commit messages add an entry to the appropriate .dir-locals.el file using git-commit-mode as the “major-mode”, setting the variable git-commit-major-mode. This usually wouldn’t work, but Magit contains code to make it work eventhough git-commit-mode isn’t actually a major-mode.

The git-commit-mode key can also be used to set other variables in the buffers used to edit commit messages. But this doesn’t have an effect in the temporary buffers used to fontify existing commit messages before inserting them into revision buffers.

If $GIT_WORK_TREE/.git is a file, then $GIT_WORK_TREE/.dir-locals.el would normally not apply when editing a file inside $GIT_DIR, such as the file that is being edited to write commit messages. But Magit explicitly uses the .dir-locals.el from the working tree unless $GIT_DIR/.dir-locals.el exists, because otherwise it would not be possible to distribute such a file in a way that would cause it to be used by all contributors.

A new mode git-commit-elisp-text-mode was added. It is intended to be used as the major-mode for commit messages for Elisp projects. It derives from text-mode and additionally highlights `symbols' and "strings". Of course you could also use text-mode (the default), markdown-mode or org-mode.

Here’s an example:

((git-commit-mode
  (git-commit-major-mode . git-commit-elisp-text-mode)))

Other changes

This release also contains many other changes and bug fixes, which are listed in the release notes. Considering how long it took, this release doesn’t contain that many truely exciting changes because most of those changes haven’t landed on the master branch yet, but that is about to change:

Roadmap

The two biggest planned changes that likely won’t make it before the end of the year are improvements to diffing and logging. Well, I will try to implement some of the planned changes to diffing by then, but logging won’t make the cut, that I am unfortainly certain off.



Comments on Reddit.