Magit is a Git user interface focused on efficient and intuitive work-flows, which will help you become a more effective Git user.

Magit is a text-based user interface to Git. It looks similar to the output of Git itself. Unlike when using Git directly, a Magit user does not execute commands by typing them into a shell. The main entry point to Magit isn't the command-line but its status buffer, which can be seen above.

Unlike the read-only output of Git, everything that you can see in the status buffer, or any other Magit buffer, is actionable. Commands are invoked, not by typing them out, but by pressing short mnemonic key sequences. Many commands act on the thing the cursor is on, either by showing more detailed or alternative information about it in a separate buffer or by performing an action with side-effects on it.

Magit streamlines work-flows to an extent not found in any other Git client. While Git offers many commands and arguments that perform a wide variety of tasks, Magit goes one step further by not only preserving that flexibility but by also providing higher-level commands that are not so much bound by the (wonderful) underlying data-model and whose design is instead primarily oriented on the actual tasks that users often have to perform.

Magit fully embraces Git. It does not limit itself to a subset of simple features. That may be what ultimately separates Magit from other Git clients; it supports and improves upon Git features that many users and developers of other Git clients apparently thought could not be reasonably mapped to a non-command-line interface.

Magit aspires to be a complete Git interface and also adds many innovative features not found in any other Git interface, including Git itself. While some gaps still exist, which have to be filled before complete feature-parity can be claimed, Magit already enables even advanced Git users to perform nearly all of their daily version control tasks with a fraction of the effort that would be required on the command line.

Magit, the magical Git interface expands on this description.

User testimonials

A sentiment shared by at least some Git users is "if only someone wrote a consistent Git interface without removing functionality". Well, Magit provides exactly that — and more, and judging from the overwhelmingly positive user feedback, I am not the only one who thinks that this is the case. Many Magit users are genuinely enthusiastic about the productivity gains it delivers and consider it to be one of Emacs' killer features.

• "I have used many Git UIs over the years, and Magit is the first one that lets me work with greater speed and safety than just using the command line." — Duncan Bayne
• "Magit is one of those rare packages which actually help you better understand the tool it provides an interface to." — Paul D. Smith
• "Magit allowed me to become very fluid with operations others wouldn't dare considering for their normal work-flow while feeling very safe." — Philippe Vaucher
• "Magit profoundly changed my understanding of Git." — Nicolas Petton
•  "Every time I use magit: How do I ...? It would be really cool if it worked like this... Oh! It does!" — Steven R. Baker

Many more user testimonials can be found here.

Articles for new users

Magit is already a very popular package among Emacs users but I think that Magit can also be an excellent Git interface for users of other editors and IDEs. However, trying out Magit is a somewhat involved task for users that are not already familiar with Emacs. To make it easier for potential users to assess whether Magit is worth that effort, I have written several articles that demonstrate what Magit has to offer and describe how I intend to make it more accessible to new users, especially to users who want to use Emacs just for the sake of Magit.

A little history

As Magit's current maintainer, I consider it a great honor that many users mention Magit alongside Org Mode as one of Emacs' killer features. It fills me with joy to hear from users who report that Magit has significantly improved their work-flows.

This success is the result of a lot of hard work by a few dedicated maintainers and even more contributors over the course of many years. Marius Vollmer released the initial version of Magit (briefly under a different name) in 2008. I would like to thank him and the maintainers who came later, for I would not even have known that I needed something like Magit had they not laid the groundwork in the early days of Git.

Since I became Magit's maintainer in 2013, I have been shouldering most of the work. At that time the code-base was in a rather disorganized state, suffering from an abundance of accidental complexity and a lack of consistency and abstractions. I want to make it very clear: I don't blame anyone for that. Rather I think that Magit was a victim of its own success. It was not originally designed to be a complete Git interface (or at least I believe it was not), but contributions over many years pushed it into that direction. Those contributions came from many different people, most of which were not familiar with the existing code. As a result, Magit reached a point where development was no longer sustainable — not without giving the code-base a complete overhaul. And so I did.

For a while development was guided by necessity. After taking care of the most problematic parts of the code-base, I had gained a better understanding of where I wanted to take Magit and of what users were expecting. I shifted my focus from making existing code abstractions and interface concepts future-proof to improving the user experience. Instead of merely adapting Git features to the Emacs interface, I focused on optimizing work-flows, making the user interface more consistent and intuitive.

By the end of that phase, Magit satisfied the expectations I had developed at its beginning. I still had many ideas for Magit, but it seemed like a good opportunity to take a break. That break turned into a third phase, lasting more than a year, during which I focused on smaller improvements and additions. This was by no means a lost year; many bugs got fixed and even more minor inconsistency got ironed out. It also gave me time to think — to refine the ideas I had come up with during the previous phase, to come up with some new ones, and to finally write the more important ones down. It did, however, mean putting those ideas, as well as some long overdue changes, on hold.

The magic must go on

If I gave up implementing the ideas that I have come up with, I think Magit's users would miss out on a lot of improvements that would prove to be just as groundbreaking as others were in the past. Also let's not forget that, despite its success, Magit is not without issues. The most significant of these is performance, and fixing just that alone requires several far-reaching and time-consuming changes.

However, the current mode of operation is not sustainable — it depends too much on one person making big sacrifices over the course of many years (with the much appreciated help of a few others). Just maintaining Magit, without moving in any new directions, is a lot of work. We get fewer feature requests now than we used to, but still enough to keep a few part-time maintainers busy. And Magit's user-base is large and diverse enough to provide a constant stream of support requests, indicating that we still need to improve the documentation and make the user interface more obvious.

I love working on Magit and would enjoy nothing more than being able to do so for another year — or more. Magit and I are at a crossroad — either I can step up my game or I have to very significantly reduce my involvement in the project. Magit is still far from fulfilling its potential and now I need your help to get it there.

Feature roadmap

Below is a summary of what I consider to be the most important of the planned changes. Along with these descriptions, you will find lists of related improvements and additions that I intend to implement.

This roadmap only covers the tip of the iceberg. An even more extensive overview of issues can be found here. Topics that are being described below tend to be located towards the left on that page, but there are some exciting ideas to be found on the right side too.

Improved performance

Performance is the most often heard complaint about Magit. Bad performance is, for the most part, caused by some very old design decisions used in core abstractions. These decisions made sense at the time, not least because they kept things simple.

The time to revisit these decisions has come. I have a good understanding of what the issues are and what difficulties are involved in overcoming them. The bad news is that doing so is a lot of work; the good news is that I also want to improve those abstractions for other reasons. Good performance will not be the only benefit of finally improving these core abstractions.

The various sources of bad performance and my plans for addressing them are briefly summarized in issue #2982.

Full collaboration support

Features that facilitate collaboration are another of Magit's weak spots. That is somewhat embarrassing, considering that this is were many other Git clients shine.

I decided to delay implementing such features because I already had enough on my hands and had to draw the line somewhere. It was easy to draw the line here because Magit didn't offer much in this area to begin with. Until now Magit was exclusively an interface to Git, but I intend to change that by supporting Github et al., because these services are also important in our version control work-flows.

A few other packages set out to fill the gap, but my expectations as to how collaboration work-flows should be optimized in Emacs are much more ambitious than what has been attempted so far.

Essentially, I expect Magit to do the same for collaboration as it already does for version control: to provide an intuitive and complete interface. This interface should not only make things easier and painless, but also encourage users to use features that seemed too daunting before. Since I have helped Magit do that for version control, I am confident I can do the same for collaboration.

Read more about this in issue #2972.

Improved history inspection

One property of Magit that sets it apart from other Git interfaces is its focus on optimizing work-flows. However, certain areas have gotten more attention in the past than others. Work-flows that are related to the creation of history (e.g. staging, committing, and merging) and to the manipulation of history (e.g. rebasing, cherry-picking, and amending) in particular are highly optimized by now. The interfaces and commands for inspecting history, on the other hand, are somewhat lacking in comparison.

One reason for this might be that the creation of commits is in a sense more essential than looking at them, and therefore users have made more requests regarding the improvement of the former. If no commits have been created, then there are no commits to look at, simple as that. In other words, if there is a bug, you cannot get around committing the fix, but you can forgo inspecting history to figure out why things were done the way they were (though the latter would make it less likely that you replace one bug with another).

But that users make fewer requests regarding history inspection would be a poor justification for neglecting features related to it. In fact, I think the opposite conclusion should be drawn from this. More effort should be put into making inspection painless and intuitive because it's a part of our work that is often skipped.

Issue #2995 is about "filling gaps in dwim behavior", most of which concern history inspection.

Diff related

• Show diff in file-visiting buffer #2952
• Diffs should optionally support syntax highlighting #2942
• Make it possible to edit diff #2938
• Show log for a line while diffing #2588

Log related

• Implement more readable and semantic log graphs #2989
• Given a commit, show log of "surrounding" commits #2990

Blame related

• Provide alternative visualizations of blame information #2937
• Support reverse blaming #3055

Spin-offs and new libraries

This is also covered in issue #2956.

Transient commands

"Magit popups", the interface used to select from a group of related commands, while being able to visually select arguments for the command that is ultimately invoked, is a popular feature.

The current implementation, however, was only intended as a temporary solution. It has some serious limitations, and the concept could be taken much further with a cleaner, more flexible implementation.

I am very exited about finally tackling this because I think it is an opportunity for real innovation that could influence many Emacs packages and possibly even text-based user interfaces other than Emacs.

You can read more about the current implementation in its manual, most of which will also apply to the new implementation. For information about the new implementation, see issue #2957.

File-handler for Git blobs and trees

A number of Git related packages, including Magit, allow visiting blobs in a buffer. Because these buffers are a not actually file-visiting buffers, they are only barely useful for the package that created them and not compatible with any of the other packages.

This can be fixed by turning blob-visiting buffers into actual file-visiting buffers. That doesn't mean that a file has to be created; it only means that a file-handler has to be defined, a feature already provided by Emacs, and used to access a remote file as if it was a local file. In the case of blobs, a file-handler would allow accessing past versions of a file as if it were the current version.

For more information, see issue #2958.

Elisp bindings for libgit2 and plumbing

Magit is slow and part of fixing that involves the use of libgit2, "a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language which supports C bindings."

Building on libgit2, I intend to create another library that provides a lot of convenience features tailored to what Git-related Emacs packages commonly have to do. I think it would be highly beneficial if independent, Git-related packages shared some low-level libraries, since that should help increase interoperability. To some extent magit-git.el could already be used for that purpose, but currently it is too disorganized and tailored to Magit's needs to be of much use to packages that do not depend on all of Magit.

Section library

The current section implementation assumes that all sections in a buffer are created at once, in sequential order, and then never modified. This limitation contributes significantly to Magit's performance issues.

Issue #2985 contains some thoughts on how to improve performance and, as a part of that, discusses changes to the section abstraction.

Rethink variables and arguments

Both Git and Emacs come with powerful and flexible configuration methods. Magit embraces Git and Emacs, which leads to conflicts regarding which setting wins.

This has lead to surprisingly few complaints in the past, probably because it's usually "Emacs" that wins, and that's what Emacs users expect. However I intend to make Magit more useful for people who do not otherwise use Emacs. One group of such potential users are die hard command line users who will be lured by the promise that Magit is "just like Git, but the output is actionable". Those users will be put off if their Git configuration is being ignored. And it only makes it worse that this isn't always the case.

See issue #2993 for more on the subject.

Make Magit more accessible to non-Emacs users

I think that Magit can be an excellent Git interface for users of other editors and IDEs. It would be a shame if its user-base continued to be limited to people who use Emacs for editing purposes.

To appeal to non-Emacs users, Magit has to be made more accessible. Additionally I intend to provide simplified Emacs configurations and documentation that teaches just enough Emacs to be able to use Magit. See Magit for users of other editors for more information.

Improve cooperation with Emacs and other packages

I am considering teaching Emacs' backup, auto-save, and undo features to use Git, as described in #2983. However, I have not yet studied the implementations of these features and cannot yet assess how difficult it would be to implement. Also, doing this would likely require changes to Emacs itself, which would have to be approved by the Emacs maintainers. Therefore, I cannot promise that this will progress beyond a proof-of-concept.

Other planned changes

• Pre-populate commit messages with a list of modified symbols #2931
• Make blobs editable, modify containing commit on save #2944
• Edit the commit that last touched the line at point #2943
• Guide fixup commits based on changed lines #3053
• Add a command to extract some commits from a branch #2921
• Cooperate with outline-minor-mode et al. #2970
•  ... and many more