One of my favorite magit tricks: cF (commit with instant fixup). This lets you add a single-line change to a commit way back somewhere in the log.
cF is the command you want for this.
Rebasing in Magit
121–130 of 144 posts
Re: Rebasing in Magit
#122Earlier quoted context omitted.
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 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.
I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts.
My most common workflow besides staging anything is (to make sure history is clean):
- split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit) - move new commit up/down the branch (doesn't require interactive rebase in GitUp) - squash up/down
(undo/redo from time to time)
As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent
> Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2]
However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason.
[1] I only have this blog post to confirm https://www.howardism.org/Technical/Emacs/magit-squashing.ht...
[2] There's another downside to GitUp: it's very slow on repos with huge histories. Probably due to the git library it's using.
Re: Rebasing in Magit
#123Earlier quoted context omitted.
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?
> Isn’t this just something that any IDE has built-in these days?
In most IDEs I feel that Git integration is an awkward badly integrated afterthought. They are also very much tied to the whatever IDE offers them in terms of available shortcuts, layouts, controls etc. (this applies to Magit, too).
Some of my idiosyncratic usage I developed with GitUp doesn't even exist in most (all?) Git tools: https://news.ycombinator.com/item?id=47329489 (see my most common workflow)
Re: Rebasing in Magit
#124Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.
As a magit lover, LazyGit is a fine replacement that works even better in some cases, but falls just short overall. Still very usable both inside and outside neovim.
Re: Rebasing in Magit
#125I 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 used to use Magit, but once I discovered LazyGit four years ago, I never looked back. No Emacs bloat and a great TUI-based UX with quick single key press actions.
This is what I need to be sold on magit over. Magit just feels slower (and definitely is slower to start if you're not already in emacs) and less intuitive.
Re: Rebasing in Magit
#126Earlier quoted context omitted.
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 separ…
Probably all true, what you say about magit and so on. Message passing values would be an idea, but with the current situation, when 1 concurrent execution units, a process, finishes its job, how does its "private" potentially modified state get merged back into the main Emacs global state? Lets say the concurrently running process creates some buffers to show, but in the meantime the user has rearranged their windows or split their view, but the concurrent process doesn't know about that, since it was after its creation time. Or maybe the user has meanwhile changed an important Emacs setting.
I think the current solutions for running things in separate threads are only for external tools. I guess to do more, a kind of protocol would need to be invented, that tells a process exactly what parts of the copied global state it may change and when it finishes, only those parts will be merged back into the main process' global state.
Maybe I understood things wrong and things are different than I understood them to be. I am not an Emacs core developer. Just a user, who watched a few videos.
Tramp can be sped up a bit. I remember seeing some blog posts about it. I guess if you need to go via more than 1 hop, it can get slow though.
What is the problem with mono repos?
Re: Rebasing in Magit
#127I 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.
I think you're missing out on magit.
With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy.
For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit.
Or magit makes it easy to stage/unstage line by line.
Re: Rebasing in Magit
#128I 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.
Profiling[1] your own repository and tweaking as necessary (possibly
disabling auto-status refresh) will likely yield significant
performance improvements.
I use magit with a very large repository (100k files, millions of commits) it's still not lightning fast like it is with smaller repositories, I'm still finding it an improvement over the CLI.
My config notes this saves me ~13 seconds in git-status
(remove-hook 'magit-status-headers-hook 'magit-insert-tags-header)
Re: Rebasing in Magit
#129Possibly related: this post about Lotus 1-2-3: https://news.ycombinator.com/item?id=47279633
The Emacs interface in general isn't massively like Lotus 1-2-3's, but magit's somewhat is. The above post goes into a bunch of detail, but what I remember most about my time using 1-2-3 (a long time ago now) was that the shortcuts were super easy to get accustomed to, because there was a prompt of some kind every step of the way. magit's rather similar prompts work well in this respect too. (Though you do still have to know how to use git. This is git, after all.)
Where there might be some more general overlap with Emacs: an apparent goal of Lotus 1-2-3 was, like Emacs, that its users would be able to automate it, and without too much bother given their knowledge of how to operate it in general. It's actually better than Emacs in this respect, because the macros seemed to be largely based on the keys you press; Emacs, by contrast, makes you jump through some hoops to figure out what the corresponding elisp for some sequence of keys might be. (The hoops are not hard to jump through! But they are there.)
(Along similar lines: Autodesk's Maya. And, to an extent, 3D Studio Max - though the scriptability there felt merely comprehensive, rather than pervasive. MaxScript was measurably less horrid than MEL though.)
Re: Rebasing in Magit
#130Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.