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

51–60 of 144 posts

Re: Rebasing in Magit

#51

Post by Joe_Cool »

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…

What hardware are you on?

On my old Ryzen 3600X running Arch it's a lot faster. Does the UI eat so much performance on OSX?

  $ time emacs -Q -e kill-emacs
  real    0m0.076s
  user    0m0.058s
  sys     0m0.018s

  $ time nvim -es --cmd 'vim.cmd("q")'
  real    0m0.028s
  user    0m0.005s
  sys     0m0.003s
vim still is a lot faster though.

Re: Rebasing in Magit

#52

Post by BigTTYGothGF »

School-Cotton wrote: post #45
8s2ngy wrote: post #41

Earlier quoted context omitted.

I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.

There would be no point to writing emacs in a language that can’t be developed interactively in a repl. Emacs being written in lisp is an essential quality.

> Emacs being written in lisp is an essential quality

Not for the parts of it I use.

Re: Rebasing in Magit

#53

Post by vvillena »

codingcareer wrote: post #19

A couple years back I was tinkering with a spacemacs setup and I loved Magit! Over the years I opted to substitute most tools with simpler, UI-based ones (like LogSeq for org-mode) but I never found a good substitution for Magit. Having a whole spacemacs setup just for one tool is a bit overkill though, so I just use basic git and accept having to deal with interactive rebases manually.

I have a Emacs + Spacemacs setup only for Magit. The base Spacemacs config works well, so I never had the need to tinker with it. Nowadays I don't care much about the rest of Emacs. It stays out of the way, and I keep happily using Magit.

Re: Rebasing in Magit

#54

Post by jwr »

One of my favorite magit tricks: cF (commit with instant fixup).

This lets you add a single-line change to a commit way back somewhere in the log.

Re: Rebasing in Magit

#55

Post by txru »

skrebbel wrote: post #32

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

These are indicated through context menus throughout specifying what the responses should be. It's a minimal UI though, and where `git rebase` is confusing magit rebase is confusing.

Re: Rebasing in Magit

#56

Post by precompute »

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…

Startup time does not matter, use the daemon. Opening a new frame is ~instantaneous.

I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest!

There's a new branch (feature/igc) with incremental garbage collection (via MPS) that makes routine actions faster. I've been using it and it has been incredibly stable and has completely eliminated stutters (which used to happen very infrequently, but were present). Also, to me, it seems like it improves latency. The cursor feels more responsive.

Re: Rebasing in Magit

#57

Post by ragall »

jonpalmisc wrote: post #30
ishouldbework wrote: post #25

Earlier quoted context omitted.

While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.

Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.

> Plus, there's no reason that starting a TUI program should be that slow.

There's no reason why it shouldn't. You seem to think that the interface obliges a program into a certain performance pattern. No such obligation exists. And Emacs isn't a TUI program, it only happens to have a terminal interface among many others.

Re: Rebasing in Magit

#58

Post by precompute »

8s2ngy wrote: post #41
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…

I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.

>a lot of cruft

Like what? Emacs is written in C and there are ports of it out there (all half-abandoned). Emacs, the way it exists, works very well.

Re: Rebasing in Magit

#59

Post by brcmthrowaway »

tambourine_man wrote: post #21
scocide wrote: post #10

Earlier quoted context omitted.

Magit was the only thing keeping me in emacs for a long time, but the neovim clone, neogit, is now 90% of the way there for my use cases, same interface same everything

I need to move to Neovim. Thanks for the nudge.

Any tips on how?

Re: Rebasing in Magit

#60

Post by precompute »

jonpalmisc wrote: post #30
ishouldbework wrote: post #25

Earlier quoted context omitted.

While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.

Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.

Emacs has globally shared buffer state amongst the frames that share the same "base frame" (no idea what this is called) or the same socket (could be wrong here).

Anyway, you can start N emacs instances and they can all have individual buffer states.

Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.

Text insertion lag is something I haven't experienced since 2019. Config issue?

project-find-file might be slow because of low gc-cons-threshold. I know consult gets around this by temporarily raising the threshold. These days, you can use the feature/igc branch to make these operations faster (although they are pretty fast anyway).

If you think emacs lacks , think again!

Post reply on HN