macsAirI 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.
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.
There are other breaking changes beside those mentioned here. See the release notes.
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.
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.
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.
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)))
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:
Next week I plan to create an initial release of the Forge package. Some of the features provided by that package exist in an early form in Magit itself. Those early implementations will be removed and users who want those features (and more) will have to install Forge.
After that I will release the Transient package and merge Magit’s
transient branch into master.
After doing the above it is time to release Magit 2.91.0.
At the beginning of December or hopefully a bit earlier Magit will
start to use the libgit module. Contrary to the initial plan this
most likely won’t be a hard dependency, which means I’ll have to
maintain two implementations of many functions.
Then I will release git-handler.el and start using that in Magit.
After doing the above it is time to release Magit 2.92.0.
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.