|
|
Subscribe / Log in / New account

Emacs and Magit

By Jonathan Corbet
July 12, 2017
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 [Status window] 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 [Log window] 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 [Blame window] 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 [Ediff window] 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.


to post comments

Emacs and Magit

Posted Jul 12, 2017 6:32 UTC (Wed) by alison (subscriber, #63752) [Link]

>it would not appear to be a winning strategy for Emacs in general.

As an FSF supporter who loves both emacs and git, I couldn't agree more. Thanks for another excellent post.

Emacs and Magit

Posted Jul 12, 2017 6:38 UTC (Wed) by flussence (guest, #85566) [Link] (5 responses)

I'm a lifelong Vim user, but I hope they resolve this without fuss. Everyone wins; Emacs gets to bundle it, the users can obtain it with less hassle, the authors gain the FSF's clout to enforce their license if it's ever needed, and the rest of the world maybe gets to see a few less people using CVS. :-)

OOC, how much paperwork does the FSF require for copyright assignment these days? Would they accept statements signed with the same GPG key as the code being turned over, or do they only take dead trees via snail mail?

Emacs and Magit

Posted Jul 12, 2017 12:08 UTC (Wed) by madscientist (subscriber, #16861) [Link]

> OOC, how much paperwork does the FSF require for copyright assignment these days?

You can provide scanned, signed paperwork via email for contributors for all countries these days (this has been available to U.S. contributors for a while now, and from some other specific countries like Germany for a shorter time, but now is available to everyone). You don't need to use snail mail.

See https://www.fsf.org/blogs/licensing/fsf-now-offering-pape...

Emacs and Magit

Posted Jul 12, 2017 12:53 UTC (Wed) by kushal (subscriber, #50806) [Link] (2 responses)

>I'm a lifelong Vim user, but I hope they resolve this without fuss. Everyone wins; Emacs gets to bundle it, the users can obtain it with less hassle, the authors gain the FSF's clout to enforce their license if it's ever needed, and the rest of the world maybe gets to see a few less people using CVS.

16 years Vim user this side, converted to Emacs and magit just over a week. Finding the whole thing amazing. https://kushaldas.in/posts/switching-to-emacs-land.html is what I experienced in the first one week.

Emacs and Magit

Posted Feb 11, 2018 22:09 UTC (Sun) by ceplm (subscriber, #41334) [Link] (1 responses)

Of course, vim users should use fugitive, a Git wrapper so awesome, it should be illegal :) https://github.com/tpope/vim-fugitive

Emacs and Magit

Posted Mar 15, 2019 2:00 UTC (Fri) by bb010g (guest, #130946) [Link]

Emacs and Magit

Posted Jul 13, 2017 15:26 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Emacs and Magit

Posted Jul 12, 2017 10:08 UTC (Wed) by aggelos (subscriber, #41752) [Link] (15 responses)

I'm probably missing something that's messing up the "user experience" for people, but I'm having difficulty seeing this as a significant issue. So I need to install an extra distribution (or MELPA) package for magit. I'm sure other people have as much use for magit as I have for gnus — perhaps they prefer to interact with git directly, use a graphical frontend or don't use git at all. Is there really such a pressing need for bundling it with emacs?

Emacs and Magit

Posted Jul 12, 2017 10:43 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

This. I use emacs and git and have never felt that I needed them integrated.

Emacs and Magit

Posted Jul 12, 2017 10:56 UTC (Wed) by nix (subscriber, #2304) [Link]

Quite. This is doubly bizarre given that the push these days is for *unbundling* things from the core and pushing them into ELPA. Are we doing all this massive amount of work just so we can avoid putting a non-ELPA package repository into the default config? That seems frankly bizarre.

Emacs and Magit

Posted Jul 13, 2017 22:52 UTC (Thu) by UnwashedMeme (guest, #98571) [Link]

When I use git on the cmdline I always `git add -p` so that I can review hunks being added to ensure what's going in is what I think it is. Frequently I see some tweak, stylistic fixup, malformed-whitespace or something that would be good to fix. I could pop back and forth between emacs and shell, or if I'm in magit i can tap enter on it takes me to the file with my cursor at that point. Aside from that magit also gives better hunk to hunk navigation and manipulation--like stage only selection from hunk.

I highly recommend you give it a try. I didn't think I had any problems with the git cmdline before, but magit does offer a slick experience above and beyond that.

Emacs and Magit

Posted Jul 12, 2017 12:22 UTC (Wed) by madscientist (subscriber, #16861) [Link] (3 responses)

Definitely agree. In fact like nix I would prefer more packages be unbundled! For example as a C++ programmer primarily these days, I find the version of cc-mode that comes with Emacs woefully outdated.

Whenever I restart Emacs (once every few weeks, when I have to reboot due to a new kernel update) I take a few minutes to run M-x package-list-packages and update to the latest versions of the external packages I use such as magit, irony, etc. I also pull the upstream version of cc-mode directly (using mercurial) to get the latest updates.

I've long wished that cc-mode was available via ELPA/MELPA rather than (or at least in addition to) being bundled with Emacs so that it would be simpler to get newer versions. I really have zero interest in tying a critical (and hotly developed!) tool like Magit into the Emacs release cycle.

I understand wanting to ship some version of Magit with Emacs, so that people have a great tool available "out of the box". But I agree with Stefan, this is all on Emacs to figure out.

Maybe instead of doing all that work to bundle or rewrite Magit, they could instead work on beefing up the packaging facilities even more: providing some kind of meta-bundle or tagging facilities where users could select "Git user", "C++ Programmer", "Python Programmer", etc. and have a coherent set of packages supporting those workflows show up as recommended, then tie that into the Emacs intro pages somehow so it's easy and obvious for new users to get started.

Emacs and Magit

Posted Jul 12, 2017 13:04 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

> providing some kind of meta-bundle or tagging facilities where users could select "Git user", "C++ Programmer", "Python Programmer", etc.

Spacemacs does this with their 'Layers' Feature.

http://spacemacs.org/layers/LAYERS.html

It provides a collection of packages and configs that are community-sourced. It makes it easy to get python support for a language that you are not familiar with, but still allow you to apply your own packages and configurations on top of it if you like. This really cuts down the time it takes to setup things like python support.

Spacemacs is based originally around Evil mode, but there isn't any reason why you can't use it in Holy mode.

When it comes to updates/copying the config around the important thing is your .spacemacs config. So when you setup a new workstation, you copy over the .spacemacs config, install emacs, pull down spacemacs git repo and then it will take care of the work of pulling down the packages from epel, melpa, etc. The spacemacs default page also has links for updating spacemacs and packages as well as diffing your .spacemacs file with the latest version.

Emacs and Magit

Posted Jul 12, 2017 13:06 UTC (Wed) by drag (guest, #31333) [Link]

> It makes it easy to get python support for a language

I guess I am not fully awake yet. I meant to say 'It makes it easy to get Emacs support for a language'

Emacs and Magit

Posted Jul 12, 2017 15:44 UTC (Wed) by NAR (subscriber, #1313) [Link]

This seems to be similar problem to the one with applications and bundled libraries. The user might want to use different (combination) of libraries or extensions than the distributor expects (and supports). What if there's a (big scary) security hole in magit?

Emacs and Magit

Posted Jul 12, 2017 12:56 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

I think it does make a difference if the package is included and maintained as part of Emacs. It will be covered in the Emacs manual, and kept up to date with future Emacs changes. More importantly, by being part of standard Emacs it becomes somehow perceived as standard, and this in itself encourages people to use it. This is a social rather than technical consideration.

But don't forget RMS's underlying reason: in order to enforce the GPL on GNU software it helps to be the sole copyright holder. That also helps if you want to relicense it later. This is an ultra-cautious approach and more than is necessary for most users or authors of free software, but I can see why the FSF does it.

Emacs and Magit

Posted Jul 14, 2017 20:30 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

You almost, but not quite, said another reason for preferring that something be bundled in Emacs, copyright FSF, to having something distributed separately with copyright owned by others: The code has more power that way to entice other people to distribute free software.

That is as much a goal for FSF as is providing useful software itself.

Emacs and Magit

Posted Jul 14, 2017 22:17 UTC (Fri) by sfeam (subscriber, #2841) [Link] (1 responses)

I totally do not follow your logic here. Why would the co-opting of already free software by requiring copyright assignment to FSF "entice other people to distribute free software"? If anything it would seem like a cautionary example in the other direction.

Emacs and Magit

Posted Jul 14, 2017 22:37 UTC (Fri) by giraffedata (guest, #1954) [Link]

Sorry for being vague.

The idea of copyleft is that you give someone code in exchange for him giving code to the world. Though he might have wanted to develop an entire software package and keep it to himself, he is enticed by the offer of a bunch of otherwise free-beer code to use that code as a base, add his own, and give his part to the world as free software.

That copyleft works a lot better if the copyright owner actually enforces it, and doesn't change his mind about using it for that purpose.

The FSF is more likely than pretty much anyone else to enforce copyright on its free software.

And many people trust that the FSF will always use its copyright this way, whereas some other random group of developers might decide later to license the code without the contribute-back condition.

So that's why some people might think having something like Magit part of Emacs (ergo owned and distributed by FSF) would be better than having it distributed by someone else.

Emacs and Magit

Posted Jul 12, 2017 16:46 UTC (Wed) by ikm (guest, #493) [Link] (1 responses)

I guess what the article tried to point out is that requiring paperwork to incorporate something to Emacs is "not a winning strategy" for the project, without implying that installing that one specific package in question separately is hard.

Winning strategies

Posted Jul 12, 2017 16:53 UTC (Wed) by corbet (editor, #1) [Link]

That's part of it, but the part about going into competition with an established and successful project because you feel the need to own the copyrights is even less of a winning strategy.

Emacs and Magit

Posted Jul 21, 2017 14:57 UTC (Fri) by tvaughan (guest, #117732) [Link]

This. I'm a 20+ year user of Emacs and I absolutely love magit. The two are totally indispensable to the work I do and yet I see no need to bundle magit with Emacs. I've also done a sizable amount of Python development and having python.el bundled with Emacs has been problematic, especially when trying out something else, like elpy or anaconda-mode. I also do a lot of Clojure development and it has never occurred to me that cider should be bundled with Emacs. But yes, if you aren't using Emacs magit could be reason enough to check it out and you're definitely missing out if you're using Emacs without magit.

Emacs and Magit

Posted Jul 22, 2017 20:52 UTC (Sat) by debacle (subscriber, #7114) [Link]

On Debian it is just: <tt>$ sudo apt install elpa-magit</tt>.

Emacs and Magit

Posted Jul 12, 2017 14:02 UTC (Wed) by amarao (guest, #87073) [Link] (2 responses)

It looks like FSF is afraid of GPL license and want to own copyright instead.

Emacs and Magit

Posted Jul 12, 2017 14:27 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Not sure how that makes sense? They created the GPL and have explained their rationale in detail for copyright assignment

https://www.gnu.org/licenses/why-assign.en.html

Agree or disagree, fear isn't a factor here

Emacs and Magit

Posted Jul 12, 2017 21:05 UTC (Wed) by dottedmag (subscriber, #18590) [Link]

The probability that copyright enforcement, cited as a primary reason for copyright assignment, will be necessary for GNU Emacs is, to put it mildly, slim.

One can argue that other GNU packages might need it, but, seriously, GNU Emacs copyright enforcement in 2017+?

Emacs and Magit

Posted Jul 12, 2017 17:09 UTC (Wed) by walkerlala (guest, #104060) [Link] (3 responses)

I really hope that there is something similar out there for vim.

Emacs and Magit

Posted Jul 12, 2017 17:56 UTC (Wed) by josh (subscriber, #17465) [Link]

fugitive (https://github.com/tpope/vim-fugitive) is exceptional; I highly recommend it.

I use :Gdiff, :Gblame, :Gcommit, and many other commands regularly. I love that I can do the equivalent of "git add -p" by using vimdiff commands, or browse backwards through blame and jump to commits.

Emacs and Magit

Posted Jul 12, 2017 18:54 UTC (Wed) by dbaker (guest, #89236) [Link]

vim-fugitive (https://github.com/tpope/vim-fugitive) is the closest I've found, but it doesn't have nearly the depth of feature as magit, but with fugitive + tig I haven't found myself wanting for more features.

Emacs and Magit

Posted Jul 20, 2017 21:46 UTC (Thu) by jreybert (guest, #117717) [Link]

Actually, there is! It is called vimagit

For the moment, it is mainly focused on the stage/commit feature, with a lot of actions possible (e.g. stage by file/hunk/line/word). And it is very stable.

It does not as much as magit because:

  • fugitive does an awesome job for Gblame, Gdiff, Gread...
  • There are features like interactive rebase, push, stash (by file/hunk/line/word) I'd like to add, when I can find some time :)
  • Emacs and Magit

    Posted Jul 12, 2017 18:10 UTC (Wed) by iabervon (subscriber, #722) [Link] (1 responses)

    It seems to me that the real reason to want to include it is for discoverability. Emacs detects that you're in a git working directory and does a bit of VCS stuff because of that, and offers git-specific features if you interact with the VCS stuff, and it would be nice if this naturally led users to all the functionality that magit has.

    I think the ideal thing would be for Emacs to know about magit as an external package with certain commands and applicability in certain situations, but only actually include a stub that will get it for you if you try to use it (if you say yes when asked if you want to install the external package). Similarly, the Emacs manual could tell you about magit and point you at the magit manual without actually including the magit manual.

    Emacs and Magit

    Posted Jul 12, 2017 21:29 UTC (Wed) by madscientist (subscriber, #16861) [Link]

    > Emacs detects that you're in a git working directory and does a bit of VCS stuff because of that, and offers git-specific features if you interact with the VCS stuff

    Not saying you're wrong about discoverability in general, but Magit works a bit differently than standard VC mode in Emacs: it uses one separate buffer to control the entire repository. That buffer displays the status of the repo, and it's where you add files, see changes to files, create commits, push, pull, merge, etc.: you don't do those things inside the individual file buffers. That is, like Git itself Magit is repository-based not file-based, which makes it very intuitive to use.

    You generally bind a key to the single magit-status command (I bound it to C-c g) and that's almost the only Emacs command you use: other commands are modal commands from within the Magit status buffer (e.g., push "s" to stage (git add) a file).

    There are a few per-file commands such as magit-blame, but 99% of the time you'll be interacting with the separate Magit buffer, rather than invoking commands in individual file buffers. So, it's not so important that there be per-buffer Git commands registered.

    Emacs and Magit

    Posted Jul 12, 2017 18:44 UTC (Wed) by cyperpunks (subscriber, #39406) [Link] (7 responses)

    MELPA should not be allowed for GNU Emacs unless all authors of packages there have done the paperwork and assigned their copyrights for the work to the Free Software Foundation.

    GNU Emacs helping users to use non-FSF software is wrong.

    Why?

    Posted Jul 12, 2017 19:03 UTC (Wed) by corbet (editor, #1) [Link]

    I still don't get why it is wrong to help users run non-FSF software. It is still free software, after all...

    Emacs and Magit

    Posted Jul 12, 2017 19:06 UTC (Wed) by pizza (subscriber, #46) [Link]

    > GNU Emacs helping users to use non-FSF software is wrong.

    What makes non-FSF software "wrong"?

    Now, if you'd said "Non-Free" software, I might agree with you. but there is plenty of software the FSF promotes use of that they do not own or control -- The Linux kernel being a notable example. I should also point out that assigning copyrights to the FSF is explicitly *not* a requirement to a project being under the "GNU" umbrella.

    Emacs and Magit

    Posted Jul 12, 2017 21:05 UTC (Wed) by clemensg (guest, #94377) [Link] (2 responses)

    Magit is licensed under GPLv3, which should be more than sufficient to include it. Why on earth does the FSF/rms need to hold the copyright?

    Emacs and Magit

    Posted Jul 13, 2017 2:23 UTC (Thu) by Abrahams (guest, #103692) [Link] (1 responses)

    It simplifies copyright enforcement.

    Emacs and Magit

    Posted Jul 13, 2017 3:55 UTC (Thu) by pj (subscriber, #4506) [Link]

    Does the FSF publish numbers on how often it's actually tried to enforce copyright for any given package?

    Emacs and Magit

    Posted Jul 21, 2017 21:45 UTC (Fri) by sebboh (guest, #105417) [Link] (1 responses)

    > MELPA should not be allowed for GNU Emacs unless [...]

    I think you mean ELPA.

    ELPA is the FSF repository for emacs packages.

    MELPA is third party. They should (and are) allowed to host whatever they want.

    Emacs and Magit

    Posted Jul 21, 2017 21:47 UTC (Fri) by sebboh (guest, #105417) [Link]

    Ack, I mean: ELPA is the *GNU* repository for emacs packages.

    Emacs and Magit

    Posted Jul 12, 2017 21:06 UTC (Wed) by dottedmag (subscriber, #18590) [Link]

    GNU began as a project to replace proprietary software with free one, and now lives on as a project to replace free software with free software.

    Emacs and Magit

    Posted Jul 13, 2017 6:07 UTC (Thu) by knuto (subscriber, #96401) [Link] (2 responses)

    An issue with git is that it is very file access intensive. I often find myself having a local
    emacs while running towards a remote file server. The first I have to disable is the default git support in emacs, otherwise the latency to the remote file system becomes prohibitive. As much as I'd like to have git integration in emacs or use another gui tool for complex rebases etc, it simply does not work well enough with that type of setup.

    Try running 'git status' on a clean kernel repository on a remote file system with eg.70 ms latency (I gave up after some 30 mins)

    On the other hand just saving files now and then even works acceptable with > 200 ms latency as long as
    the bandwidth is good enough.

    Emacs and Magit

    Posted Jul 13, 2017 21:08 UTC (Thu) by bfields (subscriber, #19510) [Link]

    I seem to recall git gaining the ability to stat files in parallel at some point, and that making git status over NFS better, but my memory could be wrong.

    Emacs and Magit

    Posted Jul 20, 2017 10:27 UTC (Thu) by njs (subscriber, #40338) [Link]

    If you use tramp-mode to open remote files, then emacs will maintain an ssh connection to the remote server and use it to run git commands there. This may or may not provide a better experience on net, but it might be worth checking out.

    magit installation

    Posted Jul 14, 2017 14:59 UTC (Fri) by spwhitton (subscriber, #71678) [Link]

    > available from the MELPA package archive or directly from GitHub

    It's also available in Debian and derivatives: apt-get install elpa-magit

    Emacs and Magit

    Posted Jul 29, 2017 3:51 UTC (Sat) by mgalgs (guest, #85461) [Link]

    > 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".

    Worth noting that there's a keybinding (`$' by default) to open the error buffer. I prefer having my error messages in an actual buffer anyways, but it would be nice to temporarily flash the error message in the minibuffer as well.

    > 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.

    Yes, Magit is really slow at logging in the kernel repo... I wrote submitted a patch a while back [1] that made it super fast but had some other graph-clobbering side-effects that the maintainer didn't like, and the patch died. There was also some talk about fixing this issue (the slowness of --graph) in git itself [2, 3] but nothing ever came of that either. I ended up relying more on status "sections", only going to the log buffer when I really really needed to because it could be so slow, a trade-off I was happy to make given the other benefits of Magit.

    [1] https://github.com/magit/magit/pull/1990
    [2] http://www.spinics.net/lists/git/msg232226.html
    [3] http://www.spinics.net/lists/git/msg232230.html


    Copyright © 2017, Eklektix, Inc.
    This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
    Comments and public postings are copyrighted by their creators.
    Linux is a registered trademark of Linus Torvalds