LWN: Comments on "Emacs and Magit"

Emacs and Magit

bb010g — Fri, 15 Mar 2019 02:00:54 +0000

I'd also highly recommend checking out gina.vim. https://github.com/lambdalisue/gina.vim

Emacs and Magit

ceplm — Sun, 11 Feb 2018 22:09:15 +0000

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

mgalgs — Sat, 29 Jul 2017 03:51:30 +0000

> 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

Emacs and Magit

debacle — Sat, 22 Jul 2017 20:52:28 +0000

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

Emacs and Magit

sebboh — Fri, 21 Jul 2017 21:47:48 +0000

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

Emacs and Magit

sebboh — Fri, 21 Jul 2017 21:45:08 +0000

> 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

tvaughan — Fri, 21 Jul 2017 14:57:10 +0000

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

jreybert — Thu, 20 Jul 2017 21:46:38 +0000

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

njs — Thu, 20 Jul 2017 10:27:31 +0000

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.

Emacs and Magit

giraffedata — Fri, 14 Jul 2017 22:37:41 +0000

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

sfeam — Fri, 14 Jul 2017 22:17:24 +0000

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

giraffedata — Fri, 14 Jul 2017 20:30:24 +0000

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.

magit installation

spwhitton — Fri, 14 Jul 2017 14:59:15 +0000

> 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

UnwashedMeme — Thu, 13 Jul 2017 22:52:27 +0000

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

bfields — Thu, 13 Jul 2017 21:08:16 +0000

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

smitty_one_each — Thu, 13 Jul 2017 15:26:47 +0000

http://spacemacs.org/ could be worth your attention.

Emacs and Magit

knuto — Thu, 13 Jul 2017 06:07:54 +0000

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

pj — Thu, 13 Jul 2017 03:55:24 +0000

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

Emacs and Magit

Abrahams — Thu, 13 Jul 2017 02:23:34 +0000

It simplifies copyright enforcement.

Emacs and Magit

madscientist — Wed, 12 Jul 2017 21:29:52 +0000

> 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

dottedmag — Wed, 12 Jul 2017 21:06:25 +0000

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

clemensg — Wed, 12 Jul 2017 21:05:18 +0000

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

dottedmag — Wed, 12 Jul 2017 21:05:17 +0000

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

pizza — Wed, 12 Jul 2017 19:06:53 +0000

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

Why?

corbet — Wed, 12 Jul 2017 19:03:07 +0000

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

dbaker — Wed, 12 Jul 2017 18:54:12 +0000

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

cyperpunks — Wed, 12 Jul 2017 18:44:57 +0000

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.

Emacs and Magit

iabervon — Wed, 12 Jul 2017 18:10:49 +0000

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

josh — Wed, 12 Jul 2017 17:56:10 +0000

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

walkerlala — Wed, 12 Jul 2017 17:09:07 +0000

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

Winning strategies

corbet — Wed, 12 Jul 2017 16:53:57 +0000

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

ikm — Wed, 12 Jul 2017 16:46:34 +0000

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.

Emacs and Magit

NAR — Wed, 12 Jul 2017 15:44:35 +0000

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

rahulsundaram — Wed, 12 Jul 2017 14:27:20 +0000

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

amarao — Wed, 12 Jul 2017 14:02:14 +0000

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

Emacs and Magit

drag — Wed, 12 Jul 2017 13:06:41 +0000

> 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

drag — Wed, 12 Jul 2017 13:04:10 +0000

> 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

epa — Wed, 12 Jul 2017 12:56:54 +0000

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

kushal — Wed, 12 Jul 2017 12:53:24 +0000

>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

madscientist — Wed, 12 Jul 2017 12:22:50 +0000

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.