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

91–100 of 144 posts

Re: Rebasing in Magit

#91

Post by lambda »

troupo wrote: post #80
znpy wrote: post #77

Earlier quoted context omitted.

> 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.

The claim was that its GUI is better than Magit's, following this claim: "Magit is absolutely the best Git GUI ever."

It may be prettier looking. I've seen many Git GUIs that are prettier than Magit.

But none of them that I've tried have ever come close to the workflow.

I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.

Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".

So no, I haven't tried that one because it's Mac only, but I'm not really seeing from the screen recordings the kind of workflow that I find so powerful in Magit.

Re: Rebasing in Magit

#92

Post by BeetleB »

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

Is there anything prominently missing in majutsu?

Re: Rebasing in Magit

#93

Post by steve1977 »

kqr wrote: post #82
znpy wrote: post #76

Earlier quoted context omitted.

> 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.

One does not simply use Emacs.

Re: Rebasing in Magit

#94

Post by BeetleB »

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.

It's because Magit is doing a lot more than just status. It executes multiple git commands to get all the information it wants to display.

As a sibling said, you can disable much of that.

Re: Rebasing in Magit

#95

Post by chriswarbo »

BeetleB wrote: post #92
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`!

Is there anything prominently missing in majutsu?

I'm still learning jj, so I'm not sure about jj things that majutsu might be missing, or what git/magit things seem "missing" but are just done differently in jj.

A couple of things I tend to notice:

- In magit, I can run a raw git shell commands by pressing `:`; majutsu doesn't seem to have that, so I use Emacs ordinary `M-!`

- The default view in majutsu (log) isn't as slick as magit's. With magit, I'll routinely open it up to look at the repo status, browse through the diffs (expanding/collapsing), staging/unstaging, etc. With majutsu, most of that requires first opening up the log, then opening up the diff of a commit.

- Staging/unstaging in magit is quite nice. The analogous workflow in jj seems to be splitting/squashing, but that feels clunkier in majutsu.

I've not opened bugs or PRs for these things, since it's mostly vibes and I don't have actual solutions to offer ;-)

EDIT: Oh, I also remembered that `jj` ignores $PAGER and uses its own built-in paging by default. That tries to act like `less`, and doesn't work well in Emacs. It can't use env vars either, unless we set its pager to something like `sh -c "$PAGER"` (see https://docs.jj-vcs.dev/latest/config/#pager ). Since my $PAGER is always `cat`, I've just set that as jj's pager directly too.

Re: Rebasing in Magit

#96

Post by Ferret7446 »

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 functionally a shell not an editor. Starting Emacs for each file is akin to starting and stopping Wayland for every web page you open.

So the miniscule increase in start time is a non issue

Re: Rebasing in Magit

#97

Post by ragall »

jonpalmisc wrote: post #62
ragall wrote: post #57

Earlier quoted context omitted.

> 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.

> 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.

Re: Rebasing in Magit

#98

Post by moritzwarhier »

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…

Personally, I'm not a Git magician, but I prefer the Git CLI for most operations.

Only exception is resolving conflicts.

The most important point for every gut IDE integration to me is that it cleanly maps to the file system and CLI state.

Re: Rebasing in Magit

#99

Post by Perz1val »

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'll never touch any git wrapper, because they've lied to me before and I can use git already. Everything that was there to be sped up has already been made into zsh functions.

Re: Rebasing in Magit

#100

Post by MereInterest »

precompute wrote: post #60
jonpalmisc wrote: post #30

Earlier quoted context omitted.

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 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 forwarding over SSH, or (c) open a remote TUI. TRAMP doesn't always play nicely with LSP servers, and remote TUIs are much, much more responsive than X11 forwarding.

Locally, the performance of emacs depends far more on the packages I load than on the GUI vs TUI, so I'm interested in hearing what overhead there would be.

Post reply on HN