Git Extensions is amazing. Too bad it's only for Windows. As nice as Magit may be, it would be even better as a standalone TUI application. I don't want to have to learn Emacs to use it.
Magit would make no sense outside of Emacs, because it's not just an extension - it's also a bunch of libs anyone can use - the way how Emacs works allows you to re-use and modify any behavior of any function with extreme granularity.
Practical example - while browsing GitHub in my browser, with a keypress I can let Emacs grab the current thing and operate on it - clone the repo, read files, review PRs and Issues, etc. I can even do these things directly from my notes, or when someone shares a url with me. This isn't part of Magit, these are my own customizations, but it would be much more difficult to achieve without Magit.
upvoting not because I think the article is great, but because I want someone to tell me (a magit user) why jj is better than using magit to interact wit git!
I am not an experienced magit user, (because I don't use emacs) so I can't really speak to this directly, but I can tell you what I understand to be the case.
Here's the motivation for jj, described by its creator (this will be on the FAQ in the next release:
The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.
Fundamentally, jj is a different VCS, not just a UI layer on top of git. And so there's a lot of differences, but they sort of sound more generic than specifically "vs what magit gives you."
I don't have time to be more lengthy at this exact moment, but I'll be curious to hear what others say, and I can come back and say more later if you're curious.
I find JJ to make things much easier for me than Git:
- No staging needed, edit your commit directly in your working directory
- Rebasing is automatic, I regularly edit historic commits and the messages
- jj absorb will automatically split and merge hunks into related ancestry commits
- Defer conflict resolution; many conflicts are resolved later by splitting/squashing/moving commits/hunks further (possible only for first-class conflicts)
- No interactive rebase needed, since jj commands automatically rebase while editing historic commits, it feels like constantly living within an interactive rebase
- Easily refer to the same revision (change) across rebase commands by using a jj change_id, without scribbling down Git commit hashes that change across a rebase
- Easily undo (+redo) your last commands through the jj operation log without having to backup the entire git repo at each step
And jj-fzf (https://github.com/tim-janik/jj-fzf/) gives me every useful jj command with a single hotkey (e.g. Ctrl-P for push, Ctrl-N for a new commit with 1+ parents, Alt-B to edit bookmarks/tags, Alt-R to rebase, Alt-Z for undo, …) while browsing the log with commit+diff preview.
Im using magit on windows for years now. It used to be that larger operations would completely clog everything up. They can still be annoying, but it’s not the dealbreaker it used to be.
I've been fighting the git CLI for over a decade and I've recently picked up lazygit so I can relate to this post. A good TUI has made git a joy to use and when I did try to pick up jj last year it seems like too much learning for too little gain.
I think git will be "good enough" version control for many years to come.
I really really want a magit version of jujutsu. Apply the same philosophy but use jj commands to achieve it. Under the hood magit still runs git commands so there are still annoyances such as (1) the need to create branches and name them, or (2) having to resolve conflicts as they happen rather then deferring to a more convenient time in the future (first-class conflicts), or (3) the equivalent of `jj evolve` for automatic rebasing.
Also I'll have to say magit simply chose much better names than git. I never understood the `--onto` argument of `git rebase` because it's such a bad name. On the other hand magit calls it rebase subset and it's immediately clear; I now use this kind of rebase almost every day.
When I was early in my career, I always thought that Git is hard and nerdy, and it is a good thing. I kinda liked it in a way, like there is some gratification in knowing all the commands and helping clueless coworkers, or knowing how to do a rebase -i and shuffle commits around and show off etc.
These days, I find myself just using the smallest subset of commands possible to do my job, and it is enough. Just add, commit, push/pull and occasional stash or merge is like 99.9% of my daily usage. I don't even remember how to revert (was it checkout -- <filename> or reset <filename> or restore <filename>?) and I'm just fine with it.
I think that git is easy. Just learn the happy path, and maybe a way or two for restoring to a known good state without deleting the whole repo, it's enough.
I believe it was git that finally made me accept that my working memory is actually below average and that I’ve coped basically my entire life by leaning on my chimpanzee-like spatial reasoning and building mind [palace] for everything, especially architectural and network topology conversations (I became the reviewer and copy-editor for the network architect for a project I wasn’t even on because someone knew me better than I did). Graph theory works a treat with this so I become the de facto VCS surgeon. It’s “just” a big, fat, straggly, 4 dimensional tree.
I try not to torture anyone with it (VCS repair) who hasn’t already exhibited a knack for graph theory. I just tell them where the man traps are and to ask if they feel like they need to go there.
I agree, but partly for that reason I use fossil for most of my hobby projects. It is less stressful to not have so many features outside of the ones I use, and to not even have to be tempted to rebase or otherwise rewrite history as that is not supported.
For work and all my older hobby projects still only use git and I used that for ages and know it quite well, but that does not mean I always feel like I need to use it instead of something simpler.
(It is also FUN to use some other tool and not just git year after year. Got to learn something new now and then.)
This is a textbook example of damning with faint praise. If your VCS's interface is so bad that it motivates you to scale back your use of any nontrivial version-control features and instead just content yourself with rudimentary file syncing, that's a case against the interface. Either the additional features are useful and you're missing out on that benefit, or they're extraneous and are saddling the tool with unnecessary baggage.
I agree people should at least learn the happy path. It really is not hard at all and it solidifies the underlying concepts.
However I find there is a huge difference between me working solo on a repo or with one or two other people versus managing a complex project with 10+ developers and multiple SKUs in the same codebase (as an example).
That's when the "neurosurgery" aspects come in. Problems were frequently caused by junior devs making mistakes in their repo management that could be a headache to untangle (again, as an example).
I really only use lazy git to review my code before commit it and I inevitably his the wrong scroll key and split the windows in half when I didn't mean to and I have to quit and restart to fix it.
That said, you'll pry that app from my cold, dead fingers.
That's some weirdest complain, sounds like standing in a fully stocked kitchen and muttering there's nothing to eat. You're using the pinnacle of malleable apps, why don't you just rebind the keys you don't like?
I’ve been using Magit at work because it’s what everyone uses, and it just does useful shit I need to do, like help me revert specific chunks from an old commit, or migrate chunks to a different branch, or whatever. Stuff that I know how to do in Git, but I’m tired and it turns out Magit is just a lot faster and more interactive.
I have a long history of hating Git UIs but somehow Magit is the one exception. I’ve done a lot of surgery on Git repos in the past so I’m no slouch on the command-line, Magit just lets me do it all faster.
I think they key to me is that it is really just helping you write git command lines. The menus are laid out exactly like the options of the relevant git sub-command, so that using Magit makes you more proficient at the CLI and vice versa. Other GUIs (including the awful ones that tend to be built into editors and IDEs) are instead hiding these details from you, so that if you are proficient at git on the CLI, you are still starting nearly from zero with the new interface and vice versa.
I used to use Fossil years ago, and I was happy with it. Then for work reasons, I had to start using git, and magit was what made switch from Fossil for my private stuff, too. I almost never resort to the git's CLI directly these days.
The only pain point is that last time I checked (2020), it was painfully slow on Windows, but as I haven't touched Windows (other than doing a bit of tech support for my parents) since then, that is not a problem for me.
How does Magit handle complex merges? The website shows simple diffs. In my experience, merging is something where a great UI can vastly simplify the process. I personally use SmartGit which I find is fantastic for diffs and resolving conflicts.
Like most of the things in Emacs - with variability that can suit [almost] every scenario - you can simply accept upstream or downstream changes with a keypress; use plain (line-by-line) diffing or 3way-merge diff UI; you can go through every hunk and precisely control things, while (if needed) rewriting the code; you can delegate the task to the external tooling;
What's great is that all that is happening in your editor - you can always bring another window next to your conflict resolution to compare with context in a different branch, revision or stash; you can jump from a diff pointing to a file to open it in Dired - directory browser and editor, where you can also get the log of changes pertaining that file only (or any marked files and dirs in the filetree). You can even ask LLM to help you at precise point, by just marking a hunk and sending a request - without context switching, without losing your focus.
Fully agree! Been using it for over 10 years by now, and it always was much more easier to use magit, than any other client. Let alone just cli.
It's so intuitive and easy. I learned cherry picking in it, and an answer about that was one my highest ranked emacs stackoverflow answer. In the times when people still used that :D
I am also very happy with it, and find 95% of task easy in git. Don't see me switching too.
But I somehow need to make the branch graph a bit more modern.
Magit is great, and yeah, the jj team is aware that a lot of people wouldn't switch until there's an equivalent tool.
It's true that there's more to jj than just the stuff magit gives you, but also, people should use the tools they find useful. If you're happy with magit, it's totally reasonable to keep using magit.
Seriously though, do grant Lisp serious consideration - Emacs only truly comprehensible through the lens of Lisp. The experience may open your eyes to an amazing, wide world of interesting possibilities - Magit is only one of them. No serious programmer and computer scientist would ever outright dismiss Lisp. I'm not saying that you're categorically will fall in love with it, but you may like it. Then, the question "should I try Emacs" would have a completely different meaning.
I've been an emacs user for 30+ years, and magit for... ~5? I've recently been on a "I need to learn vim" kick and was all in, until I realized I might have to run emacs for JUST magit which I guess is fine.
I settled for Doom emacs since it's in evil mode by default so I can still do both without running another process.
For me, the magic in Magit is how its interface is perfect for new users as well as long-time power users: new users get helpful menus to show them what options are available, but the menus display instantly and are entirely keyboard-driven, so that long-time power users who know the keystrokes by heart are not impeded one whit. There's no trade-off between power tool and beginner-friendliness here: everyone gets all the goodness all the time.
The interface builder has since been spun out as a separate library (and now included with stock Emacs!) called Transient, so there are several packages that leverage it. My favorite LLM interface (gpt.el) makes heavy use of transient menus. I've created my own transient menus for thinks like my PKM (Denote by Prot), my LSP client of choice (Eglot), and my citation manager (Citar).
However, PyCharm has a couple of git features that even lazygit doesn't have, which I find extremely useful:
- compare commits from any two branches (lazygit is limited in that respect)
- see the git history for an individual file
- diff a file between two branches / commits
- Not only you can see the log for an individual file - you can trace the evolution of a given function.
- You can diff not only branches, commits and files - you can diff them in reverse order, diff the changes since the last pull, etc.
- From the diff you can jump to the file in Dired. Dired is an Emacs' "DIRectory EDitor" - it lets you not only browse, but edit the entire [nested] file-tree as if it is a wiki page (using all the tools like multiple cursors, search&edit, etc.) and then commit changes that immediately would be reflected in the filesystem.
- You can mark some files and dirs in Diread and stage/unstage them, or even ask Magit to show the logs pertaining only those items.
- You can reorder, squash, fixup, or reword commits quickly
- Bisecting, cherry-picking, reverting, stashing, patching, etc., also very clean and intuitive
So that’s an article published as an answer to another article, but the author admits he “lost interest” and didn’t actually read the original article. And concludes that he probably doesn’t grasp all the aspects of what the topic is about, but he “doesn’t feel like it”.
43 comments
[ 4.4 ms ] story [ 54.0 ms ] threadPractical example - while browsing GitHub in my browser, with a keypress I can let Emacs grab the current thing and operate on it - clone the repo, read files, review PRs and Issues, etc. I can even do these things directly from my notes, or when someone shares a url with me. This isn't part of Magit, these are my own customizations, but it would be much more difficult to achieve without Magit.
Here's the motivation for jj, described by its creator (this will be on the FAQ in the next release:
The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.
Fundamentally, jj is a different VCS, not just a UI layer on top of git. And so there's a lot of differences, but they sort of sound more generic than specifically "vs what magit gives you."
I don't have time to be more lengthy at this exact moment, but I'll be curious to hear what others say, and I can come back and say more later if you're curious.
- No staging needed, edit your commit directly in your working directory
- Rebasing is automatic, I regularly edit historic commits and the messages
- jj absorb will automatically split and merge hunks into related ancestry commits
- Defer conflict resolution; many conflicts are resolved later by splitting/squashing/moving commits/hunks further (possible only for first-class conflicts)
- No interactive rebase needed, since jj commands automatically rebase while editing historic commits, it feels like constantly living within an interactive rebase
- Easily refer to the same revision (change) across rebase commands by using a jj change_id, without scribbling down Git commit hashes that change across a rebase
- Easily undo (+redo) your last commands through the jj operation log without having to backup the entire git repo at each step
And jj-fzf (https://github.com/tim-janik/jj-fzf/) gives me every useful jj command with a single hotkey (e.g. Ctrl-P for push, Ctrl-N for a new commit with 1+ parents, Alt-B to edit bookmarks/tags, Alt-R to rebase, Alt-Z for undo, …) while browsing the log with commit+diff preview.
Yeah, I know I should have given up Windows instead...
I think git will be "good enough" version control for many years to come.
Also I'll have to say magit simply chose much better names than git. I never understood the `--onto` argument of `git rebase` because it's such a bad name. On the other hand magit calls it rebase subset and it's immediately clear; I now use this kind of rebase almost every day.
These days, I find myself just using the smallest subset of commands possible to do my job, and it is enough. Just add, commit, push/pull and occasional stash or merge is like 99.9% of my daily usage. I don't even remember how to revert (was it checkout -- <filename> or reset <filename> or restore <filename>?) and I'm just fine with it.
I think that git is easy. Just learn the happy path, and maybe a way or two for restoring to a known good state without deleting the whole repo, it's enough.
I try not to torture anyone with it (VCS repair) who hasn’t already exhibited a knack for graph theory. I just tell them where the man traps are and to ask if they feel like they need to go there.
For work and all my older hobby projects still only use git and I used that for ages and know it quite well, but that does not mean I always feel like I need to use it instead of something simpler.
(It is also FUN to use some other tool and not just git year after year. Got to learn something new now and then.)
However I find there is a huge difference between me working solo on a repo or with one or two other people versus managing a complex project with 10+ developers and multiple SKUs in the same codebase (as an example).
That's when the "neurosurgery" aspects come in. Problems were frequently caused by junior devs making mistakes in their repo management that could be a headache to untangle (again, as an example).
https://github.com/jesseduffield/lazygit
I have no connection to this program, other than that I love it, and shill for it every time I get the chance.
That said, you'll pry that app from my cold, dead fingers.
https://github.com/magit/magit/issues/1811#issuecomment-9415...
But I find that there are cases in my workflow that I am more bothered by these things in magit than benefit I get from it.
I’ve been using Magit at work because it’s what everyone uses, and it just does useful shit I need to do, like help me revert specific chunks from an old commit, or migrate chunks to a different branch, or whatever. Stuff that I know how to do in Git, but I’m tired and it turns out Magit is just a lot faster and more interactive.
I have a long history of hating Git UIs but somehow Magit is the one exception. I’ve done a lot of surgery on Git repos in the past so I’m no slouch on the command-line, Magit just lets me do it all faster.
Where do you work?
The only pain point is that last time I checked (2020), it was painfully slow on Windows, but as I haven't touched Windows (other than doing a bit of tech support for my parents) since then, that is not a problem for me.
Like most of the things in Emacs - with variability that can suit [almost] every scenario - you can simply accept upstream or downstream changes with a keypress; use plain (line-by-line) diffing or 3way-merge diff UI; you can go through every hunk and precisely control things, while (if needed) rewriting the code; you can delegate the task to the external tooling;
What's great is that all that is happening in your editor - you can always bring another window next to your conflict resolution to compare with context in a different branch, revision or stash; you can jump from a diff pointing to a file to open it in Dired - directory browser and editor, where you can also get the log of changes pertaining that file only (or any marked files and dirs in the filetree). You can even ask LLM to help you at precise point, by just marking a hunk and sending a request - without context switching, without losing your focus.
It's true that there's more to jj than just the stuff magit gives you, but also, people should use the tools they find useful. If you're happy with magit, it's totally reasonable to keep using magit.
Yes there is - `alias vim='emacs -nw'` :)
Seriously though, do grant Lisp serious consideration - Emacs only truly comprehensible through the lens of Lisp. The experience may open your eyes to an amazing, wide world of interesting possibilities - Magit is only one of them. No serious programmer and computer scientist would ever outright dismiss Lisp. I'm not saying that you're categorically will fall in love with it, but you may like it. Then, the question "should I try Emacs" would have a completely different meaning.
I settled for Doom emacs since it's in evil mode by default so I can still do both without running another process.
The interface builder has since been spun out as a separate library (and now included with stock Emacs!) called Transient, so there are several packages that leverage it. My favorite LLM interface (gpt.el) makes heavy use of transient menus. I've created my own transient menus for thinks like my PKM (Denote by Prot), my LSP client of choice (Eglot), and my citation manager (Citar).
However, PyCharm has a couple of git features that even lazygit doesn't have, which I find extremely useful:
Magit easily does that and more: