[HN Gopher] Magit Is Amazing
___________________________________________________________________
Magit Is Amazing
Author : Bogdanp
Score : 145 points
Date : 2025-10-21 18:39 UTC (4 hours ago)
(HTM) web link (heiwiper.com)
(TXT) w3m dump (heiwiper.com)
| glitchc wrote:
| Git Extensions is amazing. Too bad it's only for Windows. As nice
| as Magit may be, it would be even better as a standalone TUI
| application. I don't want to have to learn Emacs to use it.
| anlsh wrote:
| I've got [a bit of neovim config](https://github.com/anlsh/nvim
| /blob/8b61520a5ecd752427abffc45...) which sends you straight to
| `neogit` (which is basically equivalent as far as I use it)
| when a certain env var is set.
|
| So in my .profile I've got
|
| ``` alias gg="NEOGIT_SLAVE=1 nvim" ```
|
| It's definitely not perfect but it's good enough to work for
| basic committing/rebasing flows and it's faster than booting up
| emacs for the same purpose.
| ckolkey wrote:
| Random, but on line 266 map `P` to `false` not `nil` and it
| won't show up.
| kace91 wrote:
| I've always heard about how good magit is but... the article has
| no content? It's just the author saying he's thankful for it.
| ziftface wrote:
| I've used it before when I used to use emacs and it's really
| neat and simple to use but I think lazygit is better. I think
| of lazygit as the spiritual successor of magit. If you're
| curious what that looks like you can see a descriptive video on
| their GitHub.
| eadmund wrote:
| He's also saying that Magit is so good that he doesn't
| recognise the complaints which motivate some people to switch
| from Git to Jujutsu.
|
| FWIW, I agree. Jujutsu seems fine, but Magit is fine too. Maybe
| Magit is the Blub of version control, and Jujutsu would change
| my life for the better, but ... I seem to be able to run in
| circles around my Git-CLI-using colleagues as it is.
| weichi wrote:
| upvoting not because I think the article is great, but because I
| want someone to tell me (a magit user) why jj is better than
| using magit to interact wit git!
| kccqzy wrote:
| 1. I don't want to crate named branches. Keeping track of
| branch names is extra effort I don't need.
|
| 2. `jj evolve` is excellent.
|
| 3. First-class conflicts. Even just deferring conflict
| resolution later is convenient.
| steveklabnik wrote:
| jj evolve hasn't existed for a long time, is that a typo?
| kccqzy wrote:
| Sorry. My bad. I confused it with `hg evolve`.
|
| Unrelated note: thank you for your jj tutorial!
| steveklabnik wrote:
| No worries! It is cool in hg, and may or may not make its
| way back into jj, we'll see :)
| steveklabnik wrote:
| I am not an experienced magit user, (because I don't use emacs)
| so I can't really speak to this directly, but I can tell you
| what I understand to be the case.
|
| Here's the motivation for jj, described by its creator (this
| will be on the FAQ in the next release:
|
| The project started as an experiment with the idea of
| representing the working copy by a regular commit. I
| (@martinvonz) considered how this feature would impact the Git
| CLI if it were added to Git. My conclusion was that it would
| effectively result in deprecating most existing Git commands
| and flags in favor of new commands and flags, especially
| considering I wanted to also support revsets. This seemed
| unlikely to be accepted by the Git project.
|
| Fundamentally, jj is a different VCS, not just a UI layer on
| top of git. And so there's a lot of differences, but they sort
| of sound more generic than specifically "vs what magit gives
| you."
|
| I don't have time to be more lengthy at this exact moment, but
| I'll be curious to hear what others say, and I can come back
| and say more later if you're curious.
| Lanedo wrote:
| I find JJ to make things much easier for me than Git:
|
| - No staging needed, edit your commit directly in your working
| directory
|
| - Rebasing is _automatic_ , I regularly edit historic commits
| and the messages
|
| - jj absorb will automatically split and merge hunks into
| related ancestry commits
|
| - Defer conflict resolution; many conflicts are resolved later
| by splitting/squashing/moving commits/hunks further (possible
| only for first-class conflicts)
|
| - No interactive rebase needed, since jj commands automatically
| rebase while editing historic commits, it feels like constantly
| living within an interactive rebase
|
| - Easily refer to the same revision (change) across rebase
| commands by using a jj change_id, without scribbling down Git
| commit hashes that change across a rebase
|
| - Easily undo (+redo) your last commands through the jj
| operation log _without_ having to backup the entire git repo at
| each step
|
| And jj-fzf (https://github.com/tim-janik/jj-fzf/) gives me
| every useful jj command with a single hotkey (e.g. Ctrl-P for
| push, Ctrl-N for a new commit with 1+ parents, Alt-B to edit
| bookmarks/tags, Alt-R to rebase, Alt-Z for undo, ...) while
| browsing the log with commit+diff preview.
| raincole wrote:
| I once tried to learn Emacs, but Magit's performance s on Windows
| was the last straw that made me give up.
|
| Yeah, I know I should have given up Windows instead...
| johanvts wrote:
| Im using magit on windows for years now. It used to be that
| larger operations would completely clog everything up. They can
| still be annoying, but it's not the dealbreaker it used to be.
| Babkock wrote:
| Well, yeah. But where's the article? I would like to see more
| articles about the Emacs-universe.
| forrestthewoods wrote:
| Why is this top of HN? The article doesn't even attempt to
| describe what Magit is or why it's amazing? Very weird.
| arcanemachiner wrote:
| HN is for nerds, the thing has "git" in its name, and you have
| access to Google.
|
| Your move.
| BeetleB wrote:
| HN works by upvotes.
|
| Lots of HN users like:
|
| 1. Emacs
|
| 2. Magit
|
| 3. Jujutsu
|
| Just mention these three in a blog post and you'll hit the
| front page too!
| syhol wrote:
| I've been fighting the git CLI for over a decade and I've
| recently picked up lazygit so I can relate to this post. A good
| TUI has made git a joy to use and when I did try to pick up jj
| last year it seems like too much learning for too little gain.
|
| I think git will be "good enough" version control for many years
| to come.
| kccqzy wrote:
| I really really want a magit version of jujutsu. Apply the same
| philosophy but use jj commands to achieve it. Under the hood
| magit still runs git commands so there are still annoyances such
| as (1) the need to create branches and name them, or (2) having
| to resolve conflicts as they happen rather then deferring to a
| more convenient time in the future (first-class conflicts), or
| (3) the equivalent of `jj evolve` for automatic rebasing.
|
| Also I'll have to say magit simply chose much better names than
| git. I never understood the `--onto` argument of `git rebase`
| because it's such a bad name. On the other hand magit calls it
| rebase subset and it's immediately clear; I now use this kind of
| rebase almost every day.
| syhol wrote:
| have you tried lazyjj? I was thinking about giving it a go.
| kccqzy wrote:
| No because reading its GitHub it doesn't seem better than
| magit.
| BeetleB wrote:
| What is `jj evolve`? It's not listed as one of their commands.
| steveklabnik wrote:
| Elsewhere in the thread they mentioned that they meant hg
| evolve. This feature was originally in jj but has been gone
| for a while, replaced with a simpler concept.
|
| Basically, when you modify a change, jj will automatically
| rebase all descendants. It's super useful!
| BeetleB wrote:
| Oh yeah - I know hg evolve. And yes, propagating the
| changes to all descendants is indeed awesome. When I first
| learned DVCS back around 2008-2009, I was expecting it
| would work that way, and was disappointed it didn't.
| mystifyingpoi wrote:
| When I was early in my career, I always thought that Git is hard
| and nerdy, and it is a good thing. I kinda liked it in a way,
| like there is some gratification in knowing all the commands and
| helping clueless coworkers, or knowing how to do a rebase -i and
| shuffle commits around and show off etc.
|
| These days, I find myself just using the smallest subset of
| commands possible to do my job, and it is enough. Just add,
| commit, push/pull and occasional stash or merge is like 99.9% of
| my daily usage. I don't even remember how to revert (was it
| checkout -- <filename> or reset <filename> or restore
| <filename>?) and I'm just fine with it.
|
| I think that git is easy. Just learn the happy path, and maybe a
| way or two for restoring to a known good state without deleting
| the whole repo, it's enough.
| hinkley wrote:
| I believe it was git that finally made me accept that my
| working memory is actually below average and that I've coped
| basically my entire life by leaning on my chimpanzee-like
| spatial reasoning and building mind [palace] for everything,
| especially architectural and network topology conversations (I
| became the reviewer and copy-editor for the network architect
| for a _project I wasn't even on_ because someone knew me better
| than I did). Graph theory works a treat with this so I become
| the de facto VCS surgeon. It's "just" a big, fat, straggly, 4
| dimensional tree.
|
| I try not to torture anyone with it (VCS repair) who hasn't
| already exhibited a knack for graph theory. I just tell them
| where the man traps are and to ask if they feel like they need
| to go there.
| qiine wrote:
| mind castle/palace is a perfectly valid strategy
| 1313ed01 wrote:
| I agree, but partly for that reason I use fossil for most of my
| hobby projects. It is less stressful to not have so many
| features outside of the ones I use, and to not even have to be
| tempted to rebase or otherwise rewrite history as that is not
| supported.
|
| For work and all my older hobby projects still only use git and
| I used that for ages and know it quite well, but that does not
| mean I always feel like I need to use it instead of something
| simpler.
|
| (It is also FUN to use some other tool and not just git year
| after year. Got to learn something new now and then.)
| sswatson wrote:
| This is a textbook example of damning with faint praise. If
| your VCS's interface is so bad that it motivates you to scale
| back your use of any nontrivial version-control features and
| instead just content yourself with rudimentary file syncing,
| that's a case against the interface. Either the additional
| features are useful and you're missing out on that benefit, or
| they're extraneous and are saddling the tool with unnecessary
| baggage.
| ASalazarMX wrote:
| Or, hear me out, the tool has enough features to cover a
| wider range of use cases than your own. You're not missing
| the benefit of features outside your use cases.
| bahmboo wrote:
| I agree people should at least learn the happy path. It really
| is not hard at all and it solidifies the underlying concepts.
|
| However I find there is a huge difference between me working
| solo on a repo or with one or two other people versus managing
| a complex project with 10+ developers and multiple SKUs in the
| same codebase (as an example).
|
| That's when the "neurosurgery" aspects come in. Problems were
| frequently caused by junior devs making mistakes in their repo
| management that could be a headache to untangle (again, as an
| example).
| arcanemachiner wrote:
| Lazygit is amazing:
|
| https://github.com/jesseduffield/lazygit
|
| I have no connection to this program, other than that I love it,
| and shill for it every time I get the chance.
| emerongi wrote:
| You can get comfortable with it in 5-10min and after that you
| will slowly discover that it does absolutely everything you
| could wish for.
|
| Today I'd honestly suggest to skip learning about git
| altogether (besides the basics, like branching, staging etc)
| and just start using lazygit immediately.
|
| I've seen people claim that having a clean git commit history
| is not worth the time, it takes too long to have it nice etc,
| opting to just stuff their refactor, renaming and new feature
| changes into one commit. With lazygit I spend a few extra
| minutes a day to make it nice and I've gotten compliments for
| it from others when they review my PRs, because it makes the
| review much easier.
| clockwork-dev wrote:
| Second this. Put off trying it for years because "why not just
| use a GUI" if I'm going to leave the console anyway. Turns out
| lazygit is kind of a happy middle ground and using it actually
| feels better than it looks.
| eschneider wrote:
| I really only use lazy git to review my code before commit it
| and I inevitably his the wrong scroll key and split the windows
| in half when I didn't mean to and I have to quit and restart to
| fix it.
|
| That said, you'll pry that app from my cold, dead fingers.
| onelesd wrote:
| are you talking about the diff hunk view? you can generally
| just smash Esc to back out of everything in lazygit
| spacebuffer wrote:
| Neogit is a magit inspired client for neovim. really worth
| checking out
| jvreeland wrote:
| I always see people saying magit is awesome but i really can't
| stand it. Especially the keybindings and transient which seems
| the main draw.
| klodolph wrote:
| I agree but the article doesn't explain why.
|
| I've been using Magit at work because it's what everyone uses,
| and it just _does_ useful shit I need to do, like help me revert
| specific chunks from an old commit, or migrate chunks to a
| different branch, or whatever. Stuff that I know how to do in
| Git, but I'm tired and it turns out Magit is just a lot faster
| and more interactive.
|
| I have a long history of hating Git UIs but somehow Magit is the
| one exception. I've done a lot of surgery on Git repos in the
| past so I'm no slouch on the command-line, Magit just lets me do
| it all faster.
| hinkley wrote:
| 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?
| BrenBarn wrote:
| It's an emacs package. That doesn't suggest "casual user" to
| me.
| hinkley wrote:
| TFA does not mention that at all. I kinda feel like the
| downvotes are unwarranted.
| lanstin wrote:
| 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.
| hinkley wrote:
| 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.
| klodolph wrote:
| 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_.
| agumonkey wrote:
| 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
| ElevenLathe wrote:
| I think they key to me is that it is really just helping you
| write git command lines. The menus are laid out exactly like
| the options of the relevant git sub-command, so that using
| Magit makes you more proficient at the CLI and vice versa.
| Other GUIs (including the awful ones that tend to be built into
| editors and IDEs) are instead hiding these details from you, so
| that if you are proficient at git on the CLI, you are still
| starting nearly from zero with the new interface and vice
| versa.
| facundo_olano wrote:
| > I've been using Magit at work because it's what everyone
| uses.
|
| Where do you work?
| krylon wrote:
| I used to use Fossil years ago, and I was happy with it. Then for
| work reasons, I had to start using git, and magit was what made
| switch from Fossil for my private stuff, too. I almost never
| resort to the git's CLI directly these days.
|
| The only pain point is that last time I checked (2020), it was
| painfully slow on Windows, but as I haven't touched Windows
| (other than doing a bit of tech support for my parents) since
| then, that is not a problem for me.
| johanvts wrote:
| The situation on windows is improved, not perfect but it is
| much better than it was.
| nogridbag wrote:
| How does Magit handle complex merges? The website shows simple
| diffs. In my experience, merging is something where a great UI
| can vastly simplify the process. I personally use SmartGit which
| I find is fantastic for diffs and resolving conflicts.
| johanvts wrote:
| It shows you conflicting files. I normally resolve each via
| ediff or my IDE and then go back to magit. It's not a
| diff/merge tool.
| ashton314 wrote:
| Ediff and smerge are both fun to use in Emacs.
| 0xcb0 wrote:
| Fully agree! Been using it for over 10 years by now, and it
| always was much more easier to use magit, than any other client.
| Let alone just cli. It's so intuitive and easy. I learned cherry
| picking in it, and an answer about that was one my highest ranked
| emacs stackoverflow answer. In the times when people still used
| that :D I am also very happy with it, and find 95% of task easy
| in git. Don't see me switching too. But I somehow need to make
| the branch graph a bit more modern.
| steveklabnik wrote:
| Magit is great, and yeah, the jj team is aware that a lot of
| people wouldn't switch until there's an equivalent tool.
|
| It's true that there's more to jj than just the stuff magit gives
| you, but also, people should use the tools they find useful. If
| you're happy with magit, it's totally reasonable to keep using
| magit.
| theappsecguy wrote:
| I would love to use magit buuuut I don't want to have to learn
| emacs... is there any alternative path?
| bowsamic wrote:
| Why don't you want to learn emacs? It isn't very difficult.
| It's never worth it to avoid learning
| kqr wrote:
| You can choose to not learn Emacs and still use Magit. Any LLM
| will teach you the necessary config and then Magit is its own
| set of keybinds and everything.
|
| You don't need to learn the JVM (beyond getting it installed)
| to play Minecraft and you don't need to learn Emacs to run
| Magit.
| ckolkey wrote:
| First, install doom emacs. Second, create a shell alias for
| "magit" that is bound to "emacs -nw -f magit". Then just run
| magit like any other TUI app - the fact that it's in emacs is
| easy to forget.
|
| Or, if you're into neovim, there's Neogit, which is inspired by
| magit. And if you're not, there's
| https://github.com/altsem/gitu
| mi_lk wrote:
| would you say neogit or gitu offer a dx similar to magit, or
| are there fundamental gaps
| tretiy3 wrote:
| gui app for linux with base magit features
| https://flathub.org/en/apps/io.github.aganzha.Stage
| michaelcampbell wrote:
| I've been an emacs user for 30+ years, and magit for... ~5? I've
| recently been on a "I need to learn vim" kick and was all in,
| until I realized I might have to run emacs for JUST magit which I
| guess is fine.
|
| I settled for Doom emacs since it's in evil mode by default so I
| can still do both without running another process.
| meken wrote:
| magit is the only thing I use Emacs for (well, sometimes I also
| use json-mode and json-pretty-print).
|
| I prefer Spacemacs though.
| TonyStr wrote:
| Assuming you used neovim, did you try neogit? It promises to be
| a magit clone for vim, but I'm curious how faithful it is. I've
| never used magit, so I don't understand what's so nice about
| it. Would be interesting to hear a long time emacs user's
| opinion on neogit.
| ginko wrote:
| I'm a long time emacs user and use magit as a fancy git-blame
| tool. Am I missing out on anything else it can do?
| johanvts wrote:
| Its great for any git task. I think worktrees are often
| overlooked, magit makes it very fast to switch between
| worktrees. It's great for debugging in two different commits in
| parallel and seeing exactly when some behavior differs.
| ashton314 wrote:
| For me, the magic in Magit is how its interface is perfect for
| new users as well as long-time power users: new users get helpful
| menus to show them what options are available, but the menus
| display instantly and are entirely keyboard-driven, so that long-
| time power users who know the keystrokes by heart are not impeded
| one whit. There's no trade-off between power tool and beginner-
| friendliness here: everyone gets all the goodness all the time.
|
| The interface builder has since been spun out as a separate
| library (and now included with stock Emacs!) called Transient, so
| there are several packages that leverage it. My favorite LLM
| interface (gpt.el) makes _heavy_ use of transient menus. I 've
| created my own transient menus for thinks like my PKM (Denote by
| Prot), my LSP client of choice (Eglot), and my citation manager
| (Citar).
| insane_dreamer wrote:
| I use lazygit, ftw!
|
| However, PyCharm has a couple of git features that even lazygit
| doesn't have, which I find extremely useful: -
| compare commits from any two branches (lazygit is limited in that
| respect) - see the git history for an individual file
| - diff a file between two branches / commits
___________________________________________________________________
(page generated 2025-10-21 23:01 UTC)