Hacker News Reader

Comment by hinkley | Hacker News Reader

Your comment caught my eye because as the de facto neurosurgeon, I’ve watched way, way too many UIs glitch a coworker into an impossible or unpleasant state and been the only one who didn’t immediately break eye contact. And remember they had someplace else to be. From CVS to SortaSafe to P4 to SVN. By the time I got to svn and saw the same issues I started spending political capital on convincing people to only use the CLI or maybe, maybe, JetBrains.

Usually the upvotes come from the casual users and the muttering from the heavy ones. In light of what I said, would you still recommend magit?

View on HN

I’ve never met a casual Magit user. They’re usually people who have decided to invest time in learning Emacs or Spacemacs, at the very least. Some of them have massive .emacs files and take notes in org-mode. The casual users would probably be using VS Code or Jetbrains instead.

If anything, Magit has helped me AVOID getting in a bad state, because it automatically shows me more information and context than what I get from the Git command line (despite all this fancy Git stuff I put in my prompt). When I’m committing in Magit, I see some weird hunk I didn’t mean to commit, and I can seamlessly edit it, because I’m already in the editor.

I beg to differ. I wouldn't praise magit if it was just another power user UI that required to become a black belt to do anything.

magit is a (somehow) thin layer on top of git output, and the brilliance comes from

    - keeps the information similar to git cli
    - depending on the context it allows to use indirect features (chunk staging) live from the diff
    - for most use cases it will infer obvious flags/parameters from where you're at.

    e.g: if you're on branch and start rebasing, it will soft-infer the source and target branch.
    another one, in the log view, selecting a few commits and diff will get you the diff for that range

    it basically reify the informations from the output transparently for you and reuse it where useful, saving you input and efforts multiple times per day

    - lastly very low complexity so it's quick and out of your way. every time I have to pair, my colleagues say they couldn't follow what I did because by the time I started talking about staging/pushing, I'm already finished and back to source

When I say “casual magit user”, I mean “magit user who is a casual user”, not “somebody who is a casual user of magit”. I just mean that I haven’t met people who use magit who don’t already know how to use git on the command line.

The inference of flags and parameters is also helpful, yeah. I’m remembering times where I’ve done something in magit and it’s auto-populated some commit or branch name, and I’m like, “Yup, that’s the right one” which saves me fifteen seconds of looking up the right name. It makes sense that the command-line interface to Git would expect me to be more explicit.

edamagit for vs-code is a faithful rendition of Magit as a .vsix

It's an emacs package. That doesn't suggest "casual user" to me.

It's runable as a standalone https://github.com/maio/smagit

there's a faithful conversion as edamagit for vs-code.

It's way more casual than having to know Emacs.

TFA does not mention that at all. I kinda feel like the downvotes are unwarranted.

To emacs user, not knowing that magit is emacs is worth a down vote prima facie :)

I share your horror for GUIs ineffectively hiding the version control reality; but then, despite being an emacs and casual magit user, I still mostly git add files one by one, having git diff the files one by one, and assembling the changed files into coherent groups.

I have a keyboard dance that feels like choreography or maybe, at this point, ritual prayer.

There are definitely shortcuts I could take in some scenarios but walking the safe path even though it's a little longer is the sane response especially when you can type as fast as most of us and you've been using a bourne shell as long as I have.

Or if I'm being more charitable, it's about staying outside the yellow tape lines on the factory floor. No exceptions.

It is pretty weird that it doesn't mention it.

The only downside I've found to magit is that the UI refresh can be slow with very large commits: when you're adding a thousand generated files, doing a big find/replace, etc. In the shell you'd just be running `git status` or `git diff src/foo/` or some such targeted command and would get near-instant results.

The flip side is that I've never seen magit end up in an inconsistent state, which is probably for the same reason it's slow: it's not doing anything "clever," just directly showing you the information it got from git.

> UI refresh can be slow with very large commits

That sounds like a feature.

The heart of Continuous is: if it hurts, either do it until it doesn’t hurt or stop doing it altogether.

Sounds like option B to me.

Reply on news.ycombinator.com