Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rebasing in Magit

entropicthoughts.com

Post reply on HN
Print view View original

31–40 of 144 posts

Re: Rebasing in Magit

#31

Post by taude »

mschulze wrote: post #2

I use magit daily for over 8 years now. Over that time I have showed it to many other peers, out of excitement for a tool that made me more productive and helped me learn - but I never could convince even one to use it. Maybe it's my persuasion skills, maybe tool usage is too personal - I don't know, but it makes me kind of sad. The UX of magit is just out of this world. Especially for rebasing, subset rebases (using…

I used to use Magit, but once I discovered LazyGit four years ago, I never looked back. No Emacs bloat and a great TUI-based UX with quick single key press actions.

Re: Rebasing in Magit

#33

Post by shpx »

I want to quit Magit because it's unbearably slow. In a repo with 6000 files `git status` takes 100ms but the Magit equivalent takes 2-4 seconds.

Re: Rebasing in Magit

#34

Post by w4rh4wk5 »

lambda wrote: post #9
mschulze wrote: post #2

I use magit daily for over 8 years now. Over that time I have showed it to many other peers, out of excitement for a tool that made me more productive and helped me learn - but I never could convince even one to use it. Maybe it's my persuasion skills, maybe tool usage is too personal - I don't know, but it makes me kind of sad. The UX of magit is just out of this world. Especially for rebasing, subset rebases (using…

Magit is absolutely the best Git GUI ever. Unfortunately, for most people the fact that it's part of Emacs is a blocker. And because most people use worse Git tools, they tend to use workflows that are easier with more cumbersome tools; generally just committing all kinds of junk commits to a branch, and using the "squash and merge" feature of GitHub or GitLab to clean everything in a PR/MR up into a single commit. S…

I've looked at Magit and indeed Emacs is a blocker as it's not something I'd like to pick up and maintain. I am using Fork as my primary Git GUI and am pretty happy with it. Lazygit and tig cover the few use-cases which Fork does not cover.

Re: Rebasing in Magit

#35

Post by jbstack »

troupo wrote: post #15
lambda wrote: post #9

Earlier quoted context omitted.

Magit is absolutely the best Git GUI ever. Unfortunately, for most people the fact that it's part of Emacs is a blocker. And because most people use worse Git tools, they tend to use workflows that are easier with more cumbersome tools; generally just committing all kinds of junk commits to a branch, and using the "squash and merge" feature of GitHub or GitLab to clean everything in a PR/MR up into a single commit. S…

The best gut GUI is GitUp: https://gitup.co/ Magit is not even close to be on the same level. Any insane operation you want at your fingertips.

It's Mac-only. That's a pretty serious limitation for a modern Git tool.

Re: Rebasing in Magit

#36

Post by dietr1ch »

jonpalmisc wrote: post #13

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…

> Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting

I agree, but there's ways around it. On my machine the Emacs daemon is ready before I even log-in (lingering [^0]).

I think I only restart the daemon when I update emacs and its packages, and yeah, Emacs and Spacemacs are slow, but do not slow me down.

[^0]: https://wiki.archlinux.org/title/Systemd/User#Automatic_star...

Re: Rebasing in Magit

#37

Post by ashton314 »

shpx wrote: post #33

I want to quit Magit because it's unbearably slow. In a repo with 6000 files `git status` takes 100ms but the Magit equivalent takes 2-4 seconds.

This will probably help:

    ;; Speed up magit status by removing some things
    (remove-hook 'magit-status-sections-hook 'magit-insert-tags-header)
    (remove-hook 'magit-status-sections-hook 'magit-insert-status-headers)
    (remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-pushremote)
    (remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-pushremote)
    (remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-upstream)
    (remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-upstream-or-recent)

Re: Rebasing in Magit

#38

Post by chriswarbo »

I've been using magit for years, and it's the reason I avoided giving the jujutsu VCS a try: the `jj` workflow/UI is supposedly much nicer than the `git` workflow/UI; but since I use magit more than bare `git` commands, that wasn't enough to sell me.

I finally gave it a try when I came across the majutsu package, which is a magit-like interface for jujutsu. I recommend it for Emacs/magit users wanting to try `jj`!

Re: Rebasing in Magit

#40

Post by PaulDavisThe1st »

skrebbel wrote: post #32

Ilove everything about this post. "It's super easy! Just do l-Akqr␍=u2025-06-01␍-s--tests␍b!"

from TFA:

> That looks complicated, but remember how we built it: we looked at the hints and selected one option at a time. Now, if this is a log type we’ll use often, we are going to start to be able to write out that incantation without even looking at the hints. It’s both discoverable and efficient.

Post reply on HN