Emacs and Magit
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
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
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
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
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:
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.
Posted Jul 12, 2017 6:32 UTC (Wed)
by alison (subscriber, #63752)
[Link]
As an FSF supporter who loves both emacs and git, I couldn't agree more. Thanks for another excellent post.
Posted Jul 12, 2017 6:38 UTC (Wed)
by flussence (guest, #85566)
[Link] (5 responses)
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?
Posted Jul 12, 2017 12:08 UTC (Wed)
by madscientist (subscriber, #16861)
[Link]
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.
Posted Jul 12, 2017 12:53 UTC (Wed)
by kushal (subscriber, #50806)
[Link] (2 responses)
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.
Posted Feb 11, 2018 22:09 UTC (Sun)
by ceplm (subscriber, #41334)
[Link] (1 responses)
Posted Mar 15, 2019 2:00 UTC (Fri)
by bb010g (guest, #130946)
[Link]
Posted Jul 13, 2017 15:26 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
Posted Jul 12, 2017 10:08 UTC (Wed)
by aggelos (subscriber, #41752)
[Link] (15 responses)
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.
Posted Jul 12, 2017 10:56 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Jul 13, 2017 22:52 UTC (Thu)
by UnwashedMeme (guest, #98571)
[Link]
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.
Posted Jul 12, 2017 12:22 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (3 responses)
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.
Posted Jul 12, 2017 13:04 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
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.
Posted Jul 12, 2017 13:06 UTC (Wed)
by drag (guest, #31333)
[Link]
I guess I am not fully awake yet. I meant to say 'It makes it easy to get Emacs support for a language'
Posted Jul 12, 2017 15:44 UTC (Wed)
by NAR (subscriber, #1313)
[Link]
Posted Jul 12, 2017 12:56 UTC (Wed)
by epa (subscriber, #39769)
[Link] (3 responses)
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.
Posted Jul 14, 2017 20:30 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (2 responses)
That is as much a goal for FSF as is providing useful software itself.
Posted Jul 14, 2017 22:17 UTC (Fri)
by sfeam (subscriber, #2841)
[Link] (1 responses)
Posted Jul 14, 2017 22:37 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
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.
Posted Jul 12, 2017 16:46 UTC (Wed)
by ikm (guest, #493)
[Link] (1 responses)
Posted Jul 12, 2017 16:53 UTC (Wed)
by corbet (editor, #1)
[Link]
Posted Jul 21, 2017 14:57 UTC (Fri)
by tvaughan (guest, #117732)
[Link]
Posted Jul 22, 2017 20:52 UTC (Sat)
by debacle (subscriber, #7114)
[Link]
Posted Jul 12, 2017 14:02 UTC (Wed)
by amarao (guest, #87073)
[Link] (2 responses)
Posted Jul 12, 2017 14:27 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
https://www.gnu.org/licenses/why-assign.en.html
Agree or disagree, fear isn't a factor here
Posted Jul 12, 2017 21:05 UTC (Wed)
by dottedmag (subscriber, #18590)
[Link]
One can argue that other GNU packages might need it, but, seriously, GNU Emacs copyright enforcement in 2017+?
Posted Jul 12, 2017 17:09 UTC (Wed)
by walkerlala (guest, #104060)
[Link] (3 responses)
Posted Jul 12, 2017 17:56 UTC (Wed)
by josh (subscriber, #17465)
[Link]
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.
Posted Jul 12, 2017 18:54 UTC (Wed)
by dbaker (guest, #89236)
[Link]
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:
Posted Jul 12, 2017 18:10 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (1 responses)
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.
Posted Jul 12, 2017 21:29 UTC (Wed)
by madscientist (subscriber, #16861)
[Link]
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.
Posted Jul 12, 2017 18:44 UTC (Wed)
by cyperpunks (subscriber, #39406)
[Link] (7 responses)
GNU Emacs helping users to use non-FSF software is wrong.
Posted Jul 12, 2017 19:03 UTC (Wed)
by corbet (editor, #1)
[Link]
Posted Jul 12, 2017 19:06 UTC (Wed)
by pizza (subscriber, #46)
[Link]
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.
Posted Jul 12, 2017 21:05 UTC (Wed)
by clemensg (guest, #94377)
[Link] (2 responses)
Posted Jul 13, 2017 2:23 UTC (Thu)
by Abrahams (guest, #103692)
[Link] (1 responses)
Posted Jul 13, 2017 3:55 UTC (Thu)
by pj (subscriber, #4506)
[Link]
Posted Jul 21, 2017 21:45 UTC (Fri)
by sebboh (guest, #105417)
[Link] (1 responses)
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.
Posted Jul 21, 2017 21:47 UTC (Fri)
by sebboh (guest, #105417)
[Link]
Posted Jul 12, 2017 21:06 UTC (Wed)
by dottedmag (subscriber, #18590)
[Link]
Posted Jul 13, 2017 6:07 UTC (Thu)
by knuto (subscriber, #96401)
[Link] (2 responses)
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
Posted Jul 13, 2017 21:08 UTC (Thu)
by bfields (subscriber, #19510)
[Link]
Posted Jul 20, 2017 10:27 UTC (Thu)
by njs (subscriber, #40338)
[Link]
Posted Jul 14, 2017 14:59 UTC (Fri)
by spwhitton (subscriber, #71678)
[Link]
It's also available in Debian and derivatives: apt-get install elpa-magit
Posted Jul 29, 2017 3:51 UTC (Sat)
by mgalgs (guest, #85461)
[Link]
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
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
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
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
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.
Emacs and Magit
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
Sorry for being vague.
Emacs and Magit
Emacs and Magit
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.
Winning strategies
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
I still don't get why it is wrong to help users run non-FSF software. It is still free software, after all...
Why?
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
Emacs and Magit
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.
the bandwidth is good enough.
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
Emacs and Magit
magit installation
Emacs and Magit
[2] http://www.spinics.net/lists/git/msg232226.html
[3] http://www.spinics.net/lists/git/msg232230.html