Comment by jpeloquin | Hacker News Reader

Comment by jpeloquin | Hacker News Reader

Parent Full thread

This is what sold me on magit:

1. In the magit status buffer (equivalent of git status), you can selectively stage changes by highlighting the relevant lines and pressing "a". Basically an interactive git add -p. There's also line-specific unstage and discard. This makes it easy to tidy up before committing.

2. If the cursor is on a commit, commands (show, interactive rebase, push) will take that commit ID as a default argument. It feels like you're interacting with the commits directly, which makes it easier to reason through an interactive rebase or partial push. Simple rebases like reordering or squashing recent commits take only a few seconds.

3. It seems to mostly rely on calling the core git commands and parsing their text output. The core git commands are reliable. Many git clients will hang on large (> 200 GB) repos; magit doesn't. An exception is diff colorization, but if colorization is taking too long on a big diff, Ctrl-g will make magit fall back instantly to the plain diff.

4. Has decent submodule support, in that submodules can be interacted with much like commits in the parent repo.

5. Has git annex support. (Technically, I think this is provided by another package that extends magit.)

It's not really tailored to any particular git workflow as far as I can tell. The design intent seems to be that every displayed entity should be interactive, regardless of where it is displayed.

In VSCode, you can selectively stage lines in files too, just select them in the diff, right-click, "stage selected" - I love being able to do that so easily within such a nice UI.

The big appeal of magit, at least for me, is that I can quickly do it with the keyboard. Open magit, press “s” on each hunk to stage it and magit moves to the next hunk, then “c c” to write a commit message, C-c C-c to commit, then “q” and I’m right back in the code. If you need to edit a hunk you press enter on it and it drops you into the file.

This is much much faster than doing it with the mouse, and keeps me more in “the flow”. In general Emacs becomes powerful because it’s full of little tricks that add up to much tighter feedback loops which is so helpful when coding, to keep your attention on the problem you’re trying to solve. And it is trivial to add your own “little tricks” to tighten the feedback loop for whatever you’re doing.

VSCode has an extension for that too, edamagit[0] :)

One of the big appeals of VSCode for me is the huge community around it, and the range of plugins available.

[0] https://github.com/kahole/edamagit

I get that. For me VSCode is pretty clunky in terms of replacing what I like about Emacs. Writing a plugin is way more of an exercise than writing a couple lines of elisp to change something or add some new functionality, things are not self-documenting, it's not nearly as easy to open a REPL and start poking around programmatically at open files, etc. These are the things that I value with Emacs and that make me more productive.

Yeah, there's nothing wrong with VSCode as far as I know. When I started using Magit, VSCode didn't exist. If the text editor you use isn't a hindrance—regardless of what editor it is—I'm not sure it's ever worth switching. It seems like all of them can be made to do pretty much the same things these days, which is nice because colleagues can trade tricks without having to migrate (or help others migrate) between editors.

>Many git clients will hang on large (> 200 GB) repos; magit doesn't.

Maybe it's worse with other clients(haven't used any, so I wouldn't know) but for me magit does become completely unusable in some situations, like with lots of pending changes.

For vim users fugitive is a very good plugin that does at least some of these (I'm not using it to the full extent of its capacity so I cannot be sure).

Reply on news.ycombinator.com