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

81–90 of 144 posts

Re: Rebasing in Magit

#81

Post by spudlyo »

frantathefranta wrote: post #74
spudlyo wrote: post #49

Earlier quoted context omitted.

On my M1 Mac Pro I get 0.13s wall, so not much faster than your Mac. On my i9-9900K Linux box I get 0.04s. I would think my M1 single core performance would be on par, if not faster. Perhaps it has something to do with macOS and gatekeeper, as I notice I'm not getting as high of a CPU utilization. $ gtime /opt/homebrew/bin/emacs --batch --eval '(princ (format "%s\n" emacs-version))' 30.2 0.07user 0.03system 0:00.13el…

GUI Emacs on a 12 year old processor (i5-4590) feels faster than on a M4 Pro Macbook. I think it's just something to do with the window manager on each of the systems (my experience is mostly with Wayland KDE) rather than the speed of the CPU.

I also run GUI Emacs on both Linux and macOS. I build it on Linux with --with-x-toolkit=lucid and for $REASONS I'm still on X11. I run it in a full-screen frame on its own monitor, and it does indeed feel faster.

Re: Rebasing in Magit

#82

Post by kqr »

znpy wrote: post #76
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…

> Unfortunately, for most people the fact that it's part of Emacs is a blocker. OT but i've learned the hard way not to push people into emacs. a few years ago i made the very stupid mistake of pushing some colleague to trying/learning emacs and then i found myself having to explain the same person everything as well as fix his elisp code from his ~/.emacs . Reality is, i didn't want to have that role and that collea…

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.

Re: Rebasing in Magit

#83

Post by sureglymop »

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…

It looks really cool but the thing is, having learned git just as a cli tool, I don't think any UI would convert me from that workflow.

The exception is maybe diffing, where I just use meld as the difftool.

Re: Rebasing in Magit

#84

Post by Joe_Cool »

znpy wrote: post #79
Joe_Cool wrote: post #51

Earlier quoted context omitted.

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.

> On my old Ryzen 3600X running Arch > vim still is a lot faster though. you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all. maybe try with a non-gui version of emacs (or maybe calling em…

no, this is the TUI version. X11 emacs with all the composited effects needs about 200-250ms to open (about the duration of the animation for opening and closing it). That's more like OP's timings.

Re: Rebasing in Magit

#85

Post by baq »

tcoff91 wrote: post #64
chriswarbo wrote: post #38

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`!

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.

Re: Rebasing in Magit

#86

Post by Zambyte »

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.

This is something I've never done before. Are you just repeating -o, creating a merge commit?

If that's the case, it also seems like you can do jj duplicate and repeat -o if you just want to create a branch to temporarily test against another branch and main.

Re: Rebasing in Magit

#87

Post by codygman »

Joe_Cool wrote: post #84
znpy wrote: post #79

Earlier quoted context omitted.

> On my old Ryzen 3600X running Arch > vim still is a lot faster though. you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all. maybe try with a non-gui version of emacs (or maybe calling em…

no, this is the TUI version. X11 emacs with all the composited effects needs about 200-250ms to open (about the duration of the animation for opening and closing it). That's more like OP's timings.

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

Re: Rebasing in Magit

#88

Post by finaard »

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.

The slowness on startup in my emacs mainly comes from my customizations - over the last almost 3 decades I've accumulated roughly 30k loc of custom lisp, plus a lot of 3rd party stuff.

But I typically start emacs at boot, and then it runs until I reboot. I usually have one GUI frame, and one tui frame running in tmux so I can easily attach to my emacs session from a different computer. I have an emacsclient wrapper that opens stuff from the command line in my running emacs (and also mail wrappers, so clicking on a mail link in a browser opens a mail compositor in emacs).

I'm using eyebrowse with a bunch of own convenience features for workspaces in emacs - stuff like "when I switch to a buffer it'll switch to the workspace wher e that buffer is open unless I tell it I want it here". Combine that with some custom SSH entry points and especially on the notebook where I only have one screen it's way more comfortable to use than the OS window management for a terminal/ssh session messy like me.

Re: Rebasing in Magit

#89

Post by Joe_Cool »

codygman wrote: post #87
Joe_Cool wrote: post #84

Earlier quoted context omitted.

no, this is the TUI version. X11 emacs with all the composited effects needs about 200-250ms to open (about the duration of the animation for opening and closing it). That's more like OP's timings.

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

Re: Rebasing in Magit

#90

Post by BeetleB »

znpy wrote: post #77
MainlyMortal wrote: post #68

Earlier quoted context omitted.

I upvoted you because you were unfairly downvoted. I don't even use a Mac any more after 20 years of exclusively using them but it's actually hilarious how bad magit is compared to this. It's all well and good making the most of limitations that are self imposed but people need to remember to look outside their own bubble.

> I don't even use a Mac any more after 20 years So the software is mac-only, you haven't used a mac in over 20 years so you haven't used this software and yet... you claim it's better than magit? i mean, it's very dishonest at best.

> you haven't used a mac in over 20 years

Not what he said. You misparsed.

Post reply on HN