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

111–120 of 144 posts

Re: Rebasing in Magit

#111

Post by e40 »

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…

My exact experience, though I did learn it from a co-worker, so at least he did succeed. :)

Re: Rebasing in Magit

#112

Post by truncate »

zelphirkalt wrote: post #72
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' hard to solve issue is its use of global mutable state all across the board, which makes concurrency and parallelism very hard to add properly. It will take a lot of effort to slowly carefully reduce the error/bug surface and add proper parallelism constructs, that are easy to use for any package author.

Emacs is my editor/IDE of choice and consider myself power-user. However, I'm no expert in its internals or elisp. I understand that things are built with single-thread execution in mind over decades. However, I think things still can be more async, where you can offload heavy stuff to separate thread and stream results. E.g. Magit status doesn't need to block my entire editor. It can run what it needs to do in separate thread, send the results back to main thread just for rendering when its ready. Same with say consult-ripgrep / consult-find-file / find-file-in-project etc -- doens't need to wait for it in main thread and block the render / event handling until entire result set is ready (e.g. in this case things can be streamed). As in maybe there is a way around to make this much better by message passing/streaming instead of sharing state itself?

I love Emacs, but it really just fails to be effective for me when I work on monorepos and even more so, when I'm on tramp.

Re: Rebasing in Magit

#113

Post by i_dursun »

baq wrote: post #85
tcoff91 wrote: post #64

Earlier quoted context omitted.

I really love the jjui TUI. For non-emacs users who want a great TUI for jj definitely check it out.

one thing I'm missing in jjui which jj cmdline does natively is rebase onto multiple heads - using this for quickly testing my branch on some other pr and latest main. other than that agreed, helps a lot with tedious noting down of change id prefixes.

you can do this by using the "set parents" operation (shift+m) which allows you to add/remove parents to a revision. https://idursun.github.io/jjui/revisions/set-parents/

Re: Rebasing in Magit

#114

Post by Joe_Cool »

Joe_Cool wrote: post #89
codygman wrote: post #87

Earlier quoted context omitted.

No, you need to use -nw with emacs to make it apples to apples. Then it's emacs 0m0.095s vs nvim 0m0.057s: $ time nvim -es --cmd 'vim.cmd("q")' real 0m0.057s user 0m0.016s sys 0m0.017s $ time emacs -Q -e kill-emacs real 0m0.230s user 0m0.165s sys 0m0.064s $ time emacs -nw -Q -e kill-emacs real 0m0.095s user 0m0.057s sys 0m0.017s

Shouldn't matter when I am not on GUI seat. In my SSH session with X11 forwarding there is no DISPLAY emacs could use. Tried it anyways, looks the same: $ time emacs -nw -Q -e kill-emacs real 0m0.075s user 0m0.062s sys 0m0.013s

s/with/without/

Re: Rebasing in Magit

#115

Post by qubidt »

ragall wrote: post #97
jonpalmisc wrote: post #62

Earlier quoted context omitted.

> You seem to think that the interface obliges a program into a certain performance pattern. I think all software (or at least, any text editor) regardless of interface type should launch instantly. But it's more unjustifiable with TUI programs.

Nah. Here's a counter example: the TUIs that IBM wrote for many old store chains like Home Depot. They're at least an order of magnitude faster to operate for cashiers compared to web UIs but they're somewhat slow to start due to the caching and self-checks they do. This obsession with quick boot is more of a personal preference you have than a necessity.

An inane point. Obviously it's a "preference" rather than a "requirement" that my text editor boot in less than 30 seconds. But it's also not a functional requirement that Home Depot's POS terminals take a long time to start. If you could do the same checks and caching in a few hundred milliseconds it would only improve the usability for the cashier. You haven't made a case for why some user interfaces shouldn't start instantly, only that their slow start-up _might_ be justified

Re: Rebasing in Magit

#116

Post by kqr »

tsimionescu wrote: post #107
kqr wrote: post #82

Earlier quoted context omitted.

Surely the mistake here is conflating "learning Magit" with "learning Emacs"? I can run Java applications while knowing nearly nothing about the JVM. The same is true for applications based on Emacs.

Magit is not an "application based on Emacs", it's an extremely powerful git plugin for someone who is already using Emacs . If you're not using Emacs, it would be crazy to fire up Magit just to do a git commit or rebase. Even the fact that you'd have to learn Emacs' extremely idiosyncratic keyboard shortcuts, and even keyboard shortcut help (what do you mean "save is C-x C-s?" what does that even mean?) is a huge pr…

> If you're not using Emacs, it would be crazy to fire up Magit just to do a git commit or rebase.

What makes you say that?

> what do you mean "save is C-x C-s?" what does that even mean?

Magit never asks you to C-x C-s save anything. Magit has its own independent set of discoverable keybinds.

Re: Rebasing in Magit

#118

Post by MobileVet »

w4rh4wk5 wrote: post #34
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…

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.

Run spacemacs in ‘evil mode’ so you can use Vim!

Re: Rebasing in Magit

#119

Post by precompute »

MereInterest wrote: post #100
precompute wrote: post #60

Earlier quoted context omitted.

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 overhea…

> 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. Can you elaborate on this? I tend to use emacs exclusively in the terminal, since I'm often using them on remote workstations. For remote workstations, I can (a) open files using TRAMP, (b) open a remote GUI with X11 forw…

Yes, emacs is equally performant in GUI and TUI. And frames can be opened in both GUI and TUI on the same socket.

For me, TUI is a dealbreaker because:

- No mixed-pitch support: I use mixed-pitch fonts in org-mode buffers and in outline faces in prog-mode buffers. And fonts are just plain nicer on the GUI, and it's much better to look at.

- No SVG support: (I might be wrong about this) I have a custom modeline with SVG artifacts and the artifacts fail silently on the TUI

- Keybind conflicts: I am not used to accounting for the terminal's keybinds. Also, I use xfce4-terminal, which does not support the Hyper modifier (which I use extensively).

Post reply on HN