Live data from Hacker News

Magit, the magical Git interface (2017)

emacsair.me

281–290 of 357 posts

Re: Magit, the magical Git interface (2017)

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

i agree, i do all those things using git. no reason to learn another abstraction. maybe create a few aliases to reduce typing.

Re: Magit, the magical Git interface (2017)

#283

Earlier quoted context omitted.

> Git history is intended to be immutable when working with others. That's another pet peeve (though maybe less git's fault): immutable, yes, but then rebase is pushed quite liberally. Arguably not by git itself, but by many online learning resources. It's convenient, and mostly works, but then occasionally really stings you. ...yet undoing the last commit, arguably the least aggressive of history-rewriting commands,…

It's also very wise to make sure you disallow force pushing to master/main/production. If you force push to a topic branch, it's usually ok. If you accidentally overwrite someone's changes, it's because you are working together and you can communicate that you messed up and for them to `pull --rebase` or however you want to resolve it. Usually that is. There's always room for disaster :)

--force-with-lease

Which BTW I learned it exists when magit switched "p -f u" to use it instead of plain --force.

Re: Magit, the magical Git interface (2017)

#284

Earlier quoted context omitted.

Does anyone actually do line-by-line staging using the CLI? That sounds masochistic. Most editors/GUIs make it very easy.

I ALWAYS use git commit -p. I can't count the number of times clion/intellij/pycharm or vscode have done something unexpected, and I often catch things that shouldn't be committed, e.g. logging statements, commented code, etc. It takes an extra minute, but it really helps the code quality. Every senior engineer I work with (developing trading system) does the same.

Is it not easier just to review your changes? I always read through a PR after I've sent it just in case.

Re: Magit, the magical Git interface (2017)

#285

Earlier quoted context omitted.

The default for `git reset`, which is `--mixed`, may do what you want. The difference between `--mixed` and `--soft` is that the former resets the index as well as moving the HEAD pointer; the latter only moves the HEAD, so if you’ve `git add`ed any changes, they will remain staged.

Wow this is a new level of Git hell I haven’t even heard about!

Yeah, keeping track of Git’s three areas (files, staged changes, repository) can get confusing. After some thought I think my advice to you to use `git reset --soft` would be better as just `git reset`, because that’s a neater “starting over”: it’s more of an “undo” of the last commit action, I guess. I often find myself reaching for `git reset --hard` after screwing up and not feeling like tracking down how I broke things.

Re: Magit, the magical Git interface (2017)

#286

Earlier quoted context omitted.

> Git history is intended to be immutable when working with others. That's another pet peeve (though maybe less git's fault): immutable, yes, but then rebase is pushed quite liberally. Arguably not by git itself, but by many online learning resources. It's convenient, and mostly works, but then occasionally really stings you. ...yet undoing the last commit, arguably the least aggressive of history-rewriting commands,…

It's also very wise to make sure you disallow force pushing to master/main/production. If you force push to a topic branch, it's usually ok. If you accidentally overwrite someone's changes, it's because you are working together and you can communicate that you messed up and for them to `pull --rebase` or however you want to resolve it. Usually that is. There's always room for disaster :)

> Usually that is. There's always room for disaster :)

For me, this is where the problem with got lies. I use so many of it's commands infrequently enough that I don't know where the weird disastrous edge cases are, where I should use.

I think git would greatly benefit from a topical man page; a list of common and uncommon situations that shows the recommended commands for solving them, and explains what those commands do. I know that hundreds of random "guides" exist, but are they outdated, are they cannon, do they have bugs? When your UI is esoteric, situational documentation is really important.

Re: Magit, the magical Git interface (2017)

#287

I feel like I'm missing out on a lot by not knowing emacs. I tried to learn emacs once, and the tutorial started with "I've been using emacs for about 25+ years and I'd say I'm about a middle of the road user"... that was when I was like, "No, I'll just keep using IntelliJ or vscode or whatever". It's not that I love or even care about any IDE, I just literally haven't the first clue as to even get started with emacs…

You should take a look at doom emacs.

Re: Magit, the magical Git interface (2017)

#288

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…

> Obviously, my experience must be unique

Rare, yes.

> , because everyone loves Magit. It might be the most-loved piece of software ever. Every other week, there is an article on Hacker News about how it's the best piece of software ever to exist, and I've never seen anyone say anything bad about it.

> So I wonder what marketing techniques they use to make people feel this way; the emotions are strong, and widely shared

Ah, you've lost me. Why are you dismissing the other possibility that you have bad judgement?

Re: Magit, the magical Git interface (2017)

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

> I don't feel like I'm fighting the git tools. Is this a common experience?

Yes. Today I spent way too much time explaining to a coworker that what he was complaining “should be easy to do but seems impossible” was actually quite simple, only to spend ages explaining how git works, why he wasn’t understanding the paradigm. And after all that help what he needed to do was simply to “git checkout feature-A && git merge master” we didn’t even touch on rebasing, and it’s not like he hasn’t used git before, he had at least half a decades worth of experience working with codebases managed in git.

And this is far from the first time that I’ve had to help out people with something that seems extremely straight forward to me and others who have git under our skin, but is overly complex and difficult to people who might not be experts but have worked with git for several years in a state of “minimal viable knowledge”.

Git has the same problem as it’s creator, it is arrogant, and has for way to long tried to explain the fact that new users find it difficult with “well they are just dumb” instead of accepting that it needs to make its user experience and interface more intuitive. Some of these changes are finally happening now, so I no longer have to explain why “git checkout” is used for seven completely unrelated things, but there are still tons of cases where the “straight forward way” to do something is only accessible to people who have spend way too much time doing deep dives with git and fully explored all the edge cases just for the fun of it.

It doesn’t help at all that googling issues is swamped with advice of “just force it” or “delete the repo and clone it again” which can cause permanent damage to the codebase, for a tool that is at its center suppose to avoid permanent damage to your codebase. No matter how stuck up some blinded advocates of the “git is and has always been perfect”-camp you are, everyone should understand that needing to give advice like “and if you have an issue don’t Google it, go see me or another git expert first to avoid loosing code history” is at its core spotlighting fundamental issues in the tool interface.

Re: Magit, the magical Git interface (2017)

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

I was like you for a really long time. Then, I watched someone do stuff in Magit that took longer or I struggled with to get perfect in the terminal. Took a few weeks to get comfortable, but once I did, it was really nice.
Post reply on HN