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

101–110 of 144 posts

Re: Rebasing in Magit

#101

Post by baq »

Zambyte wrote: post #86
baq wrote: post #85

Earlier quoted context omitted.

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.

yes, exactly this, multiple -o. I sometimes have two or three branches which I keep a single merge branch on top of and being able to switch out the parents is super convenient.

Re: Rebasing in Magit

#102

Post by ileonichwiesz »

troupo wrote: post #15
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…

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.

Isn’t this just something that any IDE has built-in these days? Maybe I’m missing something, but how is this fundamentally different from the built-in git timeline view from something like VSCode or Jetbrains?

Re: Rebasing in Magit

#103

Post by weaksauce »

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…

my non-command line gui version of doom emacs with a bunch of packages enabled loads up fully for me in 0.45s which is hardly slow. sure it's slower than neovim but also not slow in the absolute sense and i don't have the emacs daemon running which would make that even faster.

Re: Rebasing in Magit

#104

Post by worik »

steve1977 wrote: post #93
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.

One does not simply use Emacs.

I simply used Emacs for 25 years, avoiding editing .emacs entirely

Only in the past years have I started customizing it

My attraction to Emacs is stability and I can use it in text or GUI mode.

Many editors have come and gone in that time, many employers insist I use this or that piece of over designed, under done GUI. When I have the chance, back to Emacs

Re: Rebasing in Magit

#105

Post by mr_mitm »

moritzwarhier wrote: post #98
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…

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.

Staging single lines or hunks is also much easier in a TUI/GUI. I wouldn't even know how to do it with just git.

Re: Rebasing in Magit

#106

Post by stackbutterflow »

mr_mitm wrote: post #105
moritzwarhier wrote: post #98

Earlier quoted context omitted.

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.

Staging single lines or hunks is also much easier in a TUI/GUI. I wouldn't even know how to do it with just git.

git add -p

Re: Rebasing in Magit

#107

Post by tsimionescu »

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.

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 problem not worth the effort.

And I'm saying this as someone who has exclusively programmed in Emacs with Magit for the last 5 years in my job.

Re: Rebasing in Magit

#109

Post by badsectoracula »

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…

> Magit is absolutely the best Git GUI ever.

But it isn't graphical :-P.

Personally i've been often looking for an opensource Git GUI front end but couldn't find anything i'd like. My points of reference of decent tools -ignoring the underlying tech- are Perforce and TortoiseSVN under Windows and Fuel[0] (for Fossil) and KDESVN under Linux.

Perforce and Fuel are the two i like the most, followed by KDESVN and Tortoise. But since i'm on Linux and i stick with opensource projects, Perforce and Tortoise are out, leaving me with Fuel and KDESVN. I'm using KDESVN for a few projects where i don't care about external collaboration and want to store many binary files (which Subversion does it better that Git IMO), though KDESVN is very primitive and limited in what it supports (it doesn't support shelving at all, for example - in fact for anything beyond commit and checking the history you probably need to use the cli tool). I do not use Fossil much nowadays but i used it a lot in the past so i have a bunch of repositories in it, for which i use Fuel. Fuel is unfortunately not being developed anymore, though since it is opensource it doesn't matter much (which is a reason why i ignore anything non-opensource, i know there are some decent proprietary Git clients but for me they might as well not exist).

I think at some point i'll grab libgit2 and make something using Lazarus, probably something similar to Fuel. Unlike libsvn, which seems to be made in hell, libgit2 seems very sane and shouldn't be terribly hard to make something usable out of it.

In the meanwhile i use a combination of git cola, gitgui and gitk though they all feel like a hodgepodge of barely thought random features thrown in together (and i hate that they all want to impose their own idea of how i should format a message -especially git cola- which of course aren't identical between of them and aren't even close how i'd like to format the messages myself).

https://fuel-scm.org/fossil/index

Re: Rebasing in Magit

#110

Post by hrmtst93837 »

saila wrote: post #70
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…

Good tools can improve your workflow for sure, but it's easy enough to keep a clean history with a handful of git commands. There are two main reasons people don't do so: 1. they don't know the commands yet or 2. they just don't care (and are in an environment where there's no incentive to care). The kind of person who would try a tool like Magit and use it to discover git would have found a different route if Magit…

[flagged]
Post reply on HN