Live data from Hacker News

Magit, the magical Git interface (2017)

emacsair.me

141–150 of 357 posts

Re: Magit, the magical Git interface (2017)

#141
post #118

Earlier quoted context omitted.

> Switching cost is low, but typing cost is much greater. That typing cost is why I use a GUI. While many times I can just enter `git add -u` into the terminal, there's still plenty of times where I want to be selective about what goes into the commit. If a simple glob pattern can't do it, then I'm going to reach for the GUI where I can just click on all the things I want to add to the commit in far less time than it…

Yup. But then, clicking time (or rather, navigating your mouse) is also slow. Where Magit shines is in being a GUI (a TUI), so you're always informed on the state of the repo, but it's also fully keyboard operated, so you don't have to click on things. The popup-based paradigm for keyboard operation helps with discoverability - first few times around, you'll be going slow to learn what key does what, but after that,…

I remember when magit went from 1.x to 2.0, a couple of common commands changed keybinds and it was extremely painful to change the habits as they were commands I typed hundreds of times per day. Still it didn't take long to adapt.

Re: Magit, the magical Git interface (2017)

#142
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…

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 research to get it to do what I wanted, and I was completely confused by its choice of default behaviours, so I gave up trying. I would welcome an interactive tool that is more oriented around the way the command line tooling works, but magit does not seem to be it.

I do have magit installed however, because I really like how it controls emacs buffers while using interactive rebase. But I never use the rest of it. I have no interest in trying to memorize which hotkey does what, and how to bend yet a new interface to my will (that apparently disagrees with my preferred default behaviour), when I already know the git command line.

Re: Magit, the magical Git interface (2017)

#143
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…

Yeah, it's definitely the mnemonic single-key and terminal gui that makes magit great. That, and the genuinely low occurrence of bugs in the software.

Re: Magit, the magical Git interface (2017)

#144
post #135

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…

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…

Why would I use magit over the git CLI?

1. Discoverability. It'll display the contextually relevant options and commands at most points. By using magit, you're learning the git CLI commands at the same time, including commands that you'd normally never come across without a comprehensive read of the manual or release notes.

2. Fewer keypresses. Also, extra shortcuts for some common operations.

3. The bits that CLIs aren't very good for: staging and unstaging pieces of files, viewing conflicts.

(I do still use the Git CLI a lot of the time too.)

Re: Magit, the magical Git interface (2017)

#146
post #112

Earlier quoted context omitted.

I'm pretty sure it's the main reason. Look how many times Magit shells out to git to render the status buffer, too many to count: https://github.com/magit/magit/issues/1327 In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.

I just called the status buffer from magit on a repo. It was 23 calls to git, mostly for rev-parse. The status buffer appeared instantaneously on a decade-old laptop. Whatever is causing the slowness you're seeing, I don't think it's just because of the number of calls. It's probably the slowness of one or two specific commands, perhaps due to repo size.

Are you testing on Windows though? I am specifically talking about Windows being the (biggest) problem with this architecture. It is very expensive to create new processes on Windows versus Unix (threads are cheaper on Windows though).

Re: Magit, the magical Git interface (2017)

#147
I love magit, I’ve been using it for a year, which is as long as I’ve been using Emacs. But can someone please tell me how to pronounce magit? If I try to make it sound like magic, I pronounce it the same way as maggot, which seems wrong. If I put the emphasis on the second syllable so that it’s emphasizing git, that also feels weird.

Re: Magit, the magical Git interface (2017)

#148

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…

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.

Re: Magit, the magical Git interface (2017)

#149
post #144
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…

Why would I use magit over the git CLI? 1. Discoverability. It'll display the contextually relevant options and commands at most points. By using magit, you're learning the git CLI commands at the same time, including commands that you'd normally never come across without a comprehensive read of the manual or release notes. 2. Fewer keypresses. Also, extra shortcuts for some common operations. 3. The bits that CLIs a…

1 is really true. Magit is how I learned about workstrees!

Re: Magit, the magical Git interface (2017)

#150
post #76

Earlier quoted context omitted.

If you just want that you don't need spacemacs, just evil mode.

Well, I physically cannot take the keystroke geometry if stock emacs for any stretch of time; the space bar approach is crucial for me.

Evil mode supports leader keys. It’s pretty trivial to setup.
Post reply on HN