| ▲ | mschulze 7 hours ago |
| 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 --onto, see https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_more_...) are a breeze with Magit. I can't remember the order of branches to use on the CLI, in Magit it's just "r s" basically. It's really magic. |
|
| ▲ | lambda 7 hours ago | parent | next [-] |
| 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. So yeah, it's sad that people don't use Git to its full potential because almost no other Git interface works as well, and most people aren't going to learn Emacs just for a Git UI. |
| |
| ▲ | moritzwarhier 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | mr_mitm 2 hours ago | parent [-] | | 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. | | |
| |
| ▲ | w4rh4wk5 6 hours ago | parent | prev | next [-] | | I've looked at Magit and indeed Emacs is a blocker as it's not something I'd like to pick up and maintain. I am using Fork as my primary Git GUI and am pretty happy with it. Lazygit and tig cover the few use-cases which Fork does not cover. | | |
| ▲ | zelphirkalt 5 hours ago | parent [-] | | I am not someone to recommend VSCode, but if you are already using it, you could check out edamagit. I think in the Vim world there is also some equivalent. |
| |
| ▲ | saila 5 hours ago | parent | prev | next [-] | | 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 didn't exist. The type of person who doesn't care isn't going to learn something just because a tool is available. | | |
| ▲ | hrmtst93837 an hour ago | parent [-] | | Magit is more than a shortcut for command avoidance. It helps surface conflicts and edge cases during complex rebases and fixups, especially on big feature branches, making problems visible earlier. Relying on muscle memory alone can lead to mistakes, and using better tooling can limit the fallout when that happens. |
| |
| ▲ | badsectoracula an hour ago | parent | prev | next [-] | | > 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 | |
| ▲ | znpy 5 hours ago | parent | prev | next [-] | | > 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 colleague wasn't interested in gnu emacs in the first place. That was a very stupid mistake on my side. Nowadays i just say things like "yeah it's magit, an emacs plugin" or "ah yeah, it's nice because you spend some time learning it and then you can bring it over from company to company, no licenses involved or other annoyances". Some people are intrigued, most other absolutely aren't... And it's fine. | | |
| ▲ | kqr 4 hours ago | parent [-] | | 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. | | |
| ▲ | tsimionescu 2 hours ago | parent | next [-] | | 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. | |
| ▲ | steve1977 3 hours ago | parent | prev [-] | | One does not simply use Emacs. | | |
| ▲ | worik 2 hours ago | parent [-] | | 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 |
|
|
| |
| ▲ | imiric 5 hours ago | parent | prev | next [-] | | Peculiarly, having used Emacs for a decade as my main editor, and Git for much more than that, I never could get used to Magit. Maybe it's due to muscle memory from my CLI Git setup (nothing special, just some aliases, scmpuff, delta, etc.), or Magit forcing you into its own quirky UI, but it never clicked for me. For 99% of things I use Git for, I don't have any issues with my workflow, nor wish to improve it. For the other (very) rare occasions, I can always ask an LLM to help me figure out the right command. This is also why I don't see any value in Jujutsu either, or any of the GUI/TUI wrappers. The Git CLI porcelain with some minor customizations just hasn't been a problem I need solving. | |
| ▲ | publicdebates 5 hours ago | parent | prev | next [-] | | https://github.com/magit/magit/issues/3961 | |
| ▲ | troupo 7 hours ago | parent | prev [-] | | 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. | | |
| ▲ | jbstack 6 hours ago | parent | next [-] | | It's Mac-only. That's a pretty serious limitation for a modern Git tool. | |
| ▲ | ileonichwiesz 2 hours ago | parent | prev | next [-] | | 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? | |
| ▲ | 7 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | MainlyMortal 5 hours ago | parent | prev [-] | | 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. | | |
| ▲ | znpy 5 hours ago | parent [-] | | > 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. | | |
| ▲ | BeetleB 3 hours ago | parent | next [-] | | > you haven't used a mac in over 20 years Not what he said. You misparsed. | |
| ▲ | troupo 5 hours ago | parent | prev [-] | | The claim was that its GUI is better than Magit's, following this claim: "Magit is absolutely the best Git GUI ever." | | |
| ▲ | lambda 3 hours ago | parent [-] | | 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. |
|
|
|
|
|
|
| ▲ | masklinn 7 hours ago | parent | prev | next [-] |
| I personally don’t care for rebasing in magit (I actually find it confusing when hitting conflicts). My primary reason for using it is reviewing and staging commits. The non-linear staging with line granularity (which also lets you revert changes at the same time) is so, so very good when you care about crafting commits. |
| |
|
| ▲ | taude 7 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | e40 42 minutes ago | parent | prev | next [-] |
| My exact experience, though I did learn it from a co-worker, so at least he did succeed. :) |
|
| ▲ | sureglymop 4 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | jwr 5 hours ago | parent | prev | next [-] |
| > I never could convince even one to use it Most people think it's "just another interface on top of git" — without several in-depth examples it's difficult to realize that it actually allows you to complete really complex tasks quickly. I've seen this superficial take many times. |
|
| ▲ | zelphirkalt 5 hours ago | parent | prev | next [-] |
| Same experience here. Showed it to coworkers, but none was interested in making their tooling work well. Even looking for a VSCode equivalent for them (edamagit) no one was even willing to try. Yet people complained about many branches in repos, which didn't impact me at all, but for their GUI git clients apparently were a problem, and so we switched to deleting branches upon merge, discarding some git history along with that (when something was merged). |
|
| ▲ | jayd16 7 hours ago | parent | prev | next [-] |
| What makes something easier in magit than, for example, SmartGit? |
| |
| ▲ | mschulze 7 hours ago | parent [-] | | I haven't used SmartGit, so I can't really compare. I would single out the following for Magit: 1. Single key strokes for actions and toggles
2. Discoverability through "slide-ins" (TFA also explains this) For 2, this means I press "c" for commit, this opens a popup showing me the next keypresses and what they do.
So I can build up muscle memory for commands I know that are fast due to 1, and I can discover options that might help me due to 2. If I don't know what to do at all, there's Ctrl+c, Ctrl+c to discover "entry-points" for Magit shortcuts. | | |
| ▲ | zelphirkalt 5 hours ago | parent [-] | | I would also highlight that in Emacs magit one can always drop back to command line by pressing "!", which I do, when I don't know how to do something in Magit. Like "git submodule update --init --recursive". |
|
|
|
| ▲ | Perz1val 3 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | erksa 7 hours ago | parent | prev [-] |
| Same, emacs being the barrier for most. |