Live data from Hacker News

Rebasing in Magit

entropicthoughts.com

21–30 of 144 posts

Re: Rebasing in Magit

#21
post #10

Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.

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.

Re: Rebasing in Magit

#22

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…

/usr/bin/time emacs -Q -e kill-emacs 0.03 real 0.02 user 0.00 sys

Altough I'm not using Emacs.app.

Re: Rebasing in Magit

#23
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 personally don’t care for rebasing in magit (I actually find it confusing when hitting conflicts). My primary reason for using it is reviewing and staging commits. The non-linear staging with line granularity (which also lets you revert changes at the same time) is so, so very good when you care about crafting commits.

Right - actually, for conflicts I switch to IntelliJ.

Re: Rebasing in Magit

#24

Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.

If you haven’t seen it you may want the fugitive plugin for vim. It seems to give a reasonable level of git magic within vim. Maybe not as magic as magit, but it does a lot including good handling of interactive rebases.

Re: Rebasing in Magit

#25

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…

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.

Re: Rebasing in Magit

#26
post #10

Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.

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

Awesome! I had no idea! I will give it a shot :) Thanks ~

Re: Rebasing in Magit

#27
post #22

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…

/usr/bin/time emacs -Q -e kill-emacs 0.03 real 0.02 user 0.00 sys Altough I'm not using Emacs.app.

Not using Emacs.app because you aren't on macOS, or using some other build/setup? If the latter, I'm curious.

Re: Rebasing in Magit

#28
post #15
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.

[deleted]

Re: Rebasing in Magit

#29
post #17
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…

What makes something easier in magit than, for example, SmartGit?

I haven't used SmartGit, so I can't really compare.

I would single out the following for Magit:

1. Single key strokes for actions and toggles 2. Discoverability through "slide-ins" (TFA also explains this)

For 2, this means I press "c" for commit, this opens a popup showing me the next keypresses and what they do. So I can build up muscle memory for commands I know that are fast due to 1, and I can discover options that might help me due to 2.

If I don't know what to do at all, there's Ctrl+c, Ctrl+c to discover "entry-points" for Magit shortcuts.

Re: Rebasing in Magit

#30

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…

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.

Post reply on HN