Live data from Hacker News

Magit, the magical Git interface (2017)

emacsair.me

211–220 of 357 posts

Re: Magit, the magical Git interface (2017)

#211

I've never seen the upside. I use Emacs as my primary editor, and I regret it every time I say "today is the day I start using Magit". It is exceedingly invasive, triggering itself even when you don't ask for it (like running "git rebase -i" on the command line). The invasive stuff changes how the text editing itself works, but doesn't add deep features. In the interactive rebase case, I lose the ability to treat the…

Why would you run "git rebase -i" from the command line if you have magit? It's cool that it works, but it's far from normal. Just do it with magit and you won't get the "flashing lights". The rebase workflow in magit is one of the best parts.

Re: Magit, the magical Git interface (2017)

#213

Earlier quoted context omitted.

Same. After trying a couple of times, I haven't been able to get used to magit, and I gave up. I'm very used to the git command line interface, and magit is just too different from that. For instance, it seems to assume I want to operate only on a file, whereas most of the time I want to operate on the whole repository. I have no idea why someone would want to work like that. I found it was taking a lot of extra rese…

If you start from the magit status buffer, most things operate on the repo, except file-specific commands like staging, unstaging, etc. For those, if you run the command with your cursor on the heading, rather than with it on a file (e.g. on the “unstaged files” heading rather than on a particular file), it will ask for confirmation and apply the operation to all of the files.

More generally, magit applies operations on whatever the cursor is on, when it makes sense to do so. This is very convenient e.g. for staging parts of a change at different granularities: I can stage everything, then unstage a file, then stage a hunk within that file. It only takes a few keypresses, compared to a long set of commands followed by dredging through add -pi.

Re: Magit, the magical Git interface (2017)

#214

I've been using tig for things like this. Are they related somehow? Tig is amazing :)

I love Tig for quickly visualising and browsing the Git tree. Wish it would support interactive rebase in a more elaborate way so you could maybe reorder or amend commits from the tree view itself, instead of breaking out into Git commands.

git-imerge rebase is what you want, git-imerge is one of the coolest tools I've used.

Re: Magit, the magical Git interface (2017)

#215

Earlier quoted context omitted.

> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…

What I dislike with git terminal UI is that commands reflect the innards of git, not what the user wants to do. It also forces a deeper understanding of the innards for basic commands than ought to be necessary. Examples where undoing an operation looks totally different to doing it: - To stage a change you `add` it, to unstage you `reset HEAD` - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The l…

Yeah, git is certainly a low level tool. That's actually what I like most about it. There's a few fundamental concepts I get to manipulate directly with git commands. I like dealing with innards like this because I can form a mental model of the tool. High level tools are a lot harder to understand.

I think the problem with add, commit and reset is they aren't low level enough. The reset command in particular is juggling several concepts at once: HEAD, the index and the working tree. The add and commit commands work with fewer concepts: working tree to index and index to commit, respectively.

I too google the commands I don't use often. There's no shame in that.

Re: Magit, the magical Git interface (2017)

#216
Between using Magit and org-mode, I don't know how I could ever transition away from using emacs. I've tried to resist it, I've sworn it off and moved to exclusively using vim + command line tools for several years, and yet I keep coming back. The degree of integration between these tools is making my workflow more and more seamless over time. emacsclient has made working from multiple terminals a breeze; I don't even bother with screen or tmux anymore. And just recently I've discovered org-roam. The whole experience in emacs just keeps evolving for me.

Now if I could only find an emacs email client whose interface I can tolerate...

Re: Magit, the magical Git interface (2017)

#217
post #43

Magit is such an unbelievably good piece of software. If you haven't used it, please at least take a look. It seems like "just a GUI for git", but that's missing the point — many operations suddenly become frictionless, so your entire workflow changes. I regularly do things like "stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one,…

> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…

You probably don’t feel like you’re fighting your front door when you walk out of your house or apartment also right?

All that means is that git tools, and your front door, work well once you have mastered them. The ease of use and discoverability of tools over the life of their learning curve is what determines if they are a Norman door.

For lots of people, using a Unix command line or Git for the first time feels like a Norman door. This is why other interfaces exist (like guis) for the same tools.

What is a Normal door - 5 min Vox short https://youtu.be/yY96hTb8WgI

Re: Magit, the magical Git interface (2017)

#218
post #135

Earlier quoted context omitted.

I am the same. After the pandemic started and I had to witness over screen share how colleagues "use" (fight) git with all sorts of GUI tools, I had to realize that no GUI can be good enough while one doesn't understand git, or, even worse, it can be contraproductive, because people using these GUIs _think_ they understand, but they don't. I even ended up creating a (tailored) 2x90min git course... All that said, I h…

I gained a better understanding of git through this document: https://eagain.net/articles/git-for-computer-scientists/ I'm not a computer scientist and I think it's understandable. Everything became a lot more clear in my mind once I understood the inner workings.

That's a really cool article. The wording could be a lot simpler but the important part is that it does not abstract the concepts. They don't need to be abstracted because they are really simple. Situations can become very complex, especially when someone does not know what they are doing. Developers need to learn the priciples without lies and overzealous simplifications. If you know what's going on it's a lot more doable to not end up in a super complex situation, but not a lot of people have a really good explanation of git even if they understand it very well themselves.

Re: Magit, the magical Git interface (2017)

#219
post #9

Magit is an exceptionally well made interface to Git. Yes, it’s built on top of Emacs, and that might stop many from even looking into it. - I am glad I made a deep dive into Emacs last year, and although I stopped using it as an IDE (VS Code is just too good), I still come back to it because of Magit (and macros, general text editing and org-mode). Yes, I have an interface for Git in VS Code as well, but it‘s very r…

> I still haven‘t found out how to select several disconnected lines for staging in VS Code.

In the Source Control window, select your file then in the right panel:

- Select the first range of lines

- Alt + select the second range of lines

- Cmd + Shift + P > "Git: Stage Selected Ranges"

or in multiple steps (I usually do it like that):

- Select the first range of lines

- Cmd + Shift + P > "Git: Stage Selected Ranges"

- Select the second range of lines

- Cmd + Shift + P > "Git: Stage Selected Ranges"

Re: Magit, the magical Git interface (2017)

#220
post #29

Earlier quoted context omitted.

I've used vimagit for a long time (it's not in Lua, but it's pretty awesome): https://github.com/jreybert/vimagit

It does not really seem to be maintained anymore. Is there any downside because of that?

Looks to me like it had commits in June and August of this year. Or do you wonder whether they'll add features like pushing from within vimagit?
Post reply on HN