Live data from Hacker News

Magit, the magical Git interface (2017)

emacsair.me

171–180 of 357 posts

Re: Magit, the magical Git interface (2017)

#171

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…

I've not experienced this and I suspect most people don't is all. It's probably not personal and certainly not magic marketing sauce.

I am a magit lover and have been using it for at least a decade now and can't imagine going back to a terminal.

It's not the marketing. It just works really darn well and it speeds up my workflow.

Re: Magit, the magical Git interface (2017)

#172

Earlier quoted context omitted.

“ - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The last example is also where you get pointed to an unsafe command” Who pointed you there? If I want to undo my last commit, meaning the commit itself, not the changes to my file tree, shouldn’t I say `reset --soft`?

My bad, misgoogled. But this in fact reinforces my overall point. I don't want to be messing with `reset`, hard or soft. What is `reset`? [I now know because I had to learn, but I'd really rather not]. What I want is `uncommit`, or something like that.

git revert is probably what you want?

Re: Magit, the magical Git interface (2017)

#173
post #74

Earlier quoted context omitted.

VSCode with Gitlens is the best git GUI experience I've had. I prefer most operations via git cli, but for commiting partial changes and merge conflicts, it's everything I could ask for.

I disagree. It's ok. But it doesn't even have a DAG viewer. What kind of GUI doesn't even have `git log --tree`? Hopefully that's just because VSCode didn't allow arbitrary widgets until recently. Presumably they're working on it.

Git Graph [0] already exists as a different extension from GitLens. It works quite well, although of course it would be nice if the two extensions could integrate with each other.

[0] https://marketplace.visualstudio.com/items?itemName=mhutchie...

Re: Magit, the magical Git interface (2017)

#174
post #74
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…

VSCode with Gitlens is the best git GUI experience I've had. I prefer most operations via git cli, but for commiting partial changes and merge conflicts, it's everything I could ask for.

I just discovered that GitLens has been acquired by GitKraken. Considering that GK's entire business is "buy our premium Git GUI because the free ones suck", I have to wonder if they'll try going to intentionally wreck the extension. Fortunately it's MIT licensed.

Re: Magit, the magical Git interface (2017)

#175

Earlier quoted context omitted.

My bad, misgoogled. But this in fact reinforces my overall point. I don't want to be messing with `reset`, hard or soft. What is `reset`? [I now know because I had to learn, but I'd really rather not]. What I want is `uncommit`, or something like that.

git revert is probably what you want?

This creates a new commit that reverses the changes of a past commit. That’s different from undoing your last commit, as in, you made a commit but then changed your mind, and want, say to make some more changes before you commit. (Explained in man git-revert.)

Re: Magit, the magical Git interface (2017)

#176

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…

Just curious, are you a primary evil user?

Re: Magit, the magical Git interface (2017)

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

Sounds like the same for which I started using (and then eventually abandoned) fugitive.

Staging part of files is the only thing I found hard with cli but then fugitive or simply git difftool helps with that too (using vimdiff)

For everything else I defined my own git aliases (git graph, git mr, etc)

Re: Magit, the magical Git interface (2017)

#178

Earlier quoted context omitted.

git revert is probably what you want?

This creates a new commit that reverses the changes of a past commit. That’s different from undoing your last commit, as in, you made a commit but then changed your mind, and want, say to make some more changes before you commit. (Explained in man git-revert.)

That's by design; Git history is intended to be immutable when working with others.

But, if you haven't pushed something up to a remote, the right command to make more changes is to use `git commit --amend`.

Re: Magit, the magical Git interface (2017)

#179

Earlier quoted context omitted.

git revert is probably what you want?

This creates a new commit that reverses the changes of a past commit. That’s different from undoing your last commit, as in, you made a commit but then changed your mind, and want, say to make some more changes before you commit. (Explained in man git-revert.)

> Explained in man git-revert

If git at least had good man pages. The man-page's description is "Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them." [1] I have a hard time parsing that to mean what it's supposed to mean.

It contains a note that's much better at explaining what git revert does, then goes on to explain alternatives for other things you might want to do, but doesn't mention how to undo a commit without creating a reverting commit.

1: https://git-scm.com/docs/git-revert

Re: Magit, the magical Git interface (2017)

#180

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…

Using git for so long is almost certainly what’s up - you not only know all the various commands but “grew up” with git so you didn’t get them all in a rush. Many many people use git as cvs and are confused once it goes past “commit and push”. I know I don't really know what to do if someone pushed to master whilst I was working and it complains. Usually I just make a new checkout and merge in by hand.

I knew git at a deep level before picking up magit and I can’t disagree more with how you paint magit. Magit is the one and only git GUI that actually aligns with the git CLI and doesn’t present git as just another VCS like perforce.

I know immediately what magit is going to actually do when I use it. I could easily do everything in the terminal but I don’t because magit lets me do things so much faster and with fewer keystrokes.

Interactive staging of hunks in magit is far superior to doing the same thing with the CLI. Making interactive staging easier helps prevent hunks from ending up in the wrong commit. Oftentimes 2 different parts of a changed file in the worktree should not be in the same commit, so being able to stage hunks lightning fast in emacs is a game changer.

Here is an example of what I would do in magit with spacemacs which has evil-magit

SPC g s — pulls up magit

Tab to expand a file

s to stage

c c to commit

l L to see a detailed graph of all local branches

Move cursor to commit I want to cherry pick

A a to cherry-pick commit that my cursor is under

p p to push my branch to remote

When I’m deep in work it’s so incredibly lower friction to do that sequence of actions in magit than using git CLI.

Sure I’ll still drop down to the real thing if I need to do some really esoteric spelunking through the repo with plumbing commands but if I’m already in emacs magit is amazing.

Post reply on HN