Looking forward to using the new release. "git at the speed of thought" describes magit quite well. Actually sometimes magit nudged me into the direction of looking up some more special git commands, to learn about them and then making use of magit's interface to them, often simply pressing one button more. Magit has not made me forget how command line git works, because it often shows me right there, what the arguments are I am specifying by a few key presses actually are. If it made me forget how to use actual git, I would be thinking: "Meh, but I should know how to use git actually, for the times when I do not have magit around." Fortunately this is not the case at all with magit.
Magit has a great mix of direct manipulation of git primitives and good visualization. I think I've learned how git works faster through Magit than I would have from using the CLI. It's really hit a sweet spot for me.
I'm sure you know this, but for the benefit of other readers, pressing '$' in Magit status buffer (and likely bunch of others) pops up a buffer that lists actual commands issued to Git, so you can always check how Magit interaction maps to Git CLI commands.
Magit must be one of the best software tools ever written.
I sorely missed it when I had to use IntelliJ for a few projects, so I wrote a TUI tool like Magit that can be used inside the console window of most IDEs like IntelliJ etc.
Still haven't gotten around to releasing it properly, but it's easy to setup and works well enough to be a working MVP.
Would the need for a pure terminal magit be resolved by the fact that Emacs can run in the terminal? [1] seems to have a solution to obtain a fast starting subset of Emacs and start into magit-status directly.
I wish Git would have some kind of command-server mode or libgit2 was supported with Magit to prevent needing to create new processes on Windows. Magit sometimes creates dozens of Git processes for a single operation, but because process creation is much slower on Windows than Linux, it makes Magit unusable for me on those systems. (Sadly, I don't always get a choice to just use Linux.) Simple things like magit-status take 10 seconds per refresh/stage/unstage instead of half a second elsewhere. It got to the point where using the git command line was much more bearable, but way more error-prone, and I miss Magit every time.
Magit already has some basic support for libgit. Browsing the issues I get the impression that if someone made a reasonable pull request to support libgit2 for a few dozen methods (should be easy to prioritise based on profiling) then it would be accepted. I don’t think the maintainer wants to review pull requests for one function at a time. I think one issue is perhaps that windows performance isn’t a particularly high priority and changes may not be accepted if they degrade Linux performance.
Aside: isn’t process creation more reasonable with WSL? Or can you not easily use it?
I also can't use magit because of this. I thought the poor
performance came mostly from my big repository with lots of
binary files but now I 'git-filter-repo'ed the .git-directory
from 2-3 GB (packed) down to 150 MB and magit is still no fun at
all (although better than before).
I upvoted you but... How comes Emacs is laggy for you? I'm running a beefy Emacs setup and it is really responsive. If anything Emacs in the nineties was "Eight Megabytes And Constantly Swapping" but... We're in 2021 now and now it's still 8 MB, so it's a rounding error (I'm only exaggerating a bit).
It's one my lightest app: starting Emacs, eval'ing some elisp, and exiting takes... 81 ms. Eighty-one milliseconds. To start an entire Emacs instance from scratch (no "daemon" trickery: a real full Emacs instance), eval'ing "kill emacs" (ok, a small program if any bu still) and exiting.
I don't know which editor, in this day and age, can start and exit in 81 ms (besides vim and nano)?
Launching my full setup takes 1.1s: thousands of lines of elisp configuration.
I'm running the native-comp branch since six months (?): compilation of Emacs itself is a bit of a pain but running it is very smooth.
That's on a 6 or 7 years old Core i7 6700K / 16 GB of RAM. Hardly a speed demon (besides the NVMe M.2 PCIe 3.0 x4 SSD).
Configuration, IIRC, has got a few "tricks" to prevent the usual culprits from slowing Emacs: something to do probably with font-locking on very long lines (?) when I open such a file etc.
But it's overall more than snappy. I use ivy/avy/swiper and burntsushi's rigpgrep integrated into Emacs. Everything is not just fast but really fast.
I cannot even imagine on a modern machine like some AMD 5900X or Apple M1...
I was a longtime Emacs user (and vim before that) and recently a project I was working on was far too laggy for me to actually work productively on in Emacs. It was largely due to me using various LSPs within Emacs -- the frontend was in TypeScript and the backend in Go, and inevitably things would grind to a halt on a 5 year old i7 MBP with 16GB of RAM.
Switched over to VSCode with as many extensions as I could find to get me close to my Emacs setup (including edamagit) and it, to my surprise, was actually very productive. I've been using VSCode now for 6 months and 15 year old me in the 90s is very mad at current me for selling out.
I have the exact same story. Multiple LSPs in emacs was too hard to manage and seeing as some of it was typescript, much worse than the VSCode experience. Edamagit has made a very good start at emulating magit in VSCode. Still use emacs for magit though.
It's probably too late for you :), but I use native-comp Emacs and it's blazing fast. At least lsp-mode+gopls is. I haven't gotten the chance to use this setup with Typescript's LS, but I've used gopls+clangd without slow downs.
I have the same experience. Being on master and nativecomp probably helps, and I also think eglot is tad smoother than lsp-mode. I am using 10 year old laptop, no friction at all with tsserver, elixir-ls or gopls. However I think the server itself is the biggest difference maker, because all hell breaks lose when I try dart/flutter even in a simple project. But to be fair, my neovim setup struggles with that too (nvim-lspconfig + nvim-compe).
I use Dart/Flutter LSP (lsp-dart) in Emacs all the time very successfully. “All hell breaks loose” sounds like maybe you have a project cloned or created but not yet `flutter pub get`’d, in which case I have seen it act like practically every token is an error.
Okay, I think I am hitting some weirdness in Dart-mode itself. But it's to do with something unrelated in my config perhaps, because now I can't reproduce this with `emacs -Q`, and my dart-mode setup itself is only `(use-package dart-mode)`.
Basically even doing something mundane like C-n/C-p in a dart-mode buffer takes up a lot of memory (~800mb), which causes very high GC pressure and everything visibly stutters. Here is the `profiler-report` output just now:
Emacs is still (AFAIK) entirely single-threaded. If you are performing some operation that blocks (e.g. a network call, a shell command such as "git clone") all other windows are blocked until that completes.
I would guess if you have something like FlyMake configured for on-the-fly syntax checking, you could also get a "laggy" feeling.
Just launching and using a vanilla emacs session feels quite snappy in my experience.
you don't need multiple threads to run things concurrently (such as network I/O, communicating with subprocesses) e.g., I believe url-retrieve in emacs doesn't stop the world (because there is -synchroniously version too). async is a thing
magit runs git clone and such asynchronously. There's usable concurrency support in Emacs for things like network calls and external processes even though UI and pure elisp stuff is still single-threaded
I know that these "works for me" discussion are often not fruitful. But, I'll ask this: have you done a several hour session of typing/programming into a JetBrains IDE? I'm claiming that on my work Macbook Pro, even just typing plain text into a file and scrolling lines in IDEA is smoother and more responsive than doing the same in Emacs.
I use the Vim plugin for IDEA and evil mode in Emacs. Even things like holding 'j' or 'k' to scroll lines is painful in Emacs compared to IDEA.
I'll admit that if I spend some hours/days in Emacs, I stop noticing it much, so it isn't THAT egregious. But if I switch back and forth, it really sucks.
Something is definitely wrong with your configuration (in a wide sense, not necessarily restricted to just the editor).
Emacs is at least an order of magnitude more responsive than IDEA (or any other JetBrains IDE). Start with a stock Emacs, no extra third party packages loaded, to get a sense of performance. There is a lot of great Emacs Lisp code out there, but the opposite is also true: Horrible code written by folks new to Emacs and Emacs Lisp, that can slow down Emacs a lot and contribute to a degraded experience. Which is why I recommend starting from scratch and incrementally adding third party code/configuration (ideally, understanding the code as you go along and avoiding packages with lots of dependencies).
Personally, I find that normally emacs latency is more than tolerable. But LSP is pretty bad, at least with clang-lsp, especially on a fairly loaded machine. I have yet to try the jit branch though.
It's really hard to tell. The configurability of emacs is both a blessing and a curse. Since you can customize basically anything, there are all sorts of opportunities for funky config or a weird extension to slow things down.
I know, for example, that a lot of people who have tried both report that Doom Emacs is much faster than Spacemacs. That implies to me that it's not evil mode. For my part (fairly vanilla Doom setup), I find holding j/k to scroll in Doom is snappier than IntelliJ, on the same computer.
But then, I've also heard people complain that it's just the opposite on Windows, where Doom emacs is apparently just really laggy.
That said, I agree that the "works for me" discussions aren't very fruitful, and I'm definitely not here to tell you which editor to use. More observing that, what with how... emacsy... emacs is, you're definitely not alone. It's entirely possible that the problem you had is both something specific to how you had things set up, and also absolutely not at all your fault.
I use emacs as my main editor, but as with all software it's easy to accidentally create situations where it gets laggy, regardless of hardware. Two that I've hit over the past 10 years: (1) On Windows only, movement of point in buffers with non-ascii characters lagged when said characters were visible due to frequent gc pauses. Was fixed by making emacs wait longer to do gc, and only when idle. (2) A theme that styled text with a box around it (customize-face) made buffer redisplay laggy. Not sure why; just turned it off.
It's most likely a Mac thing. And is probably the main reason I gave up on OS X as a serious work OS, since I'm so dependent on Emacs (org-mode in particular). I hope it gets sorted one day. Apparently it has to do with certain system calls on OS X just being very slow.
Emacs on MacOS was also laggy for me before I started using the native comp feature. It takes a while to compile but it's seriously one of the best QoL changes I've had in years.
Does Emacs native-comp work outside X (i.e. works with the Cocoa port)? I thought it only worked through XQuartz b.c. gcc can’t parse the Objective-C required for the Cocoa port…
If the Cocoa port runs well, well that changes everything to me
This is my experience as well. I know it can be fast because emacs absolutely screams on my Linux machines, but it's super sluggish on the Mac I have to use for work.
Fwiw, I'm not seeing lag on my end doing the same. Can turn on magit blame and it still scrolls fine. :(
Opening a very large file?
Edit: I have found that if I don't reboot my Mac, the environment that a launcher emacs finds is sometimes off. Is it the same slow if you launch from a terminal versus the dock?
I don't think anyone really wants to profile their editor. That said, if you have the cycles to spare, M-x profiler-start, scroll, M-x profiler-stop may have some obvious culprit.
I have a very underpowered Macos machine (2010 Mac mini) which faces latency problems with most things. Except Emacs. E.g., Eshell is much snappier for issuing shell commands than bash on iTerm2.
Same. I have to work with large separated value files and it can get Emacs chugging on my Mac Book. Also any file large file that has any sort of highlighting (I.E a large xml file) can be difficult to work with.
I'm hoping that GCC emacs will resolve some of these issues. A better Elisp backend will do so much for Emacs and all of it's modes. I think one of Guilemacs goals was to have a better elisp interpreter but I'm not sure they will ever be able to keep up with all the development that has been happening on Emacs
I think it's a Mac and an HDPI thing. I had to stop using emacs because it was too slow on my work MacBook Pro connected to a 4K screen. Scrolling was painful and only marginally better with nativecomp.
If you are interested in continuing to use emacs, I'd suggest using the profiler to investigate. There's a good demo/depiction of doing that here: https://www.murilopereira.com/how-to-open-a-file-in-emacs/ (posted recently to HN). I think it's most likely to be something pretty specific/small in the config you're using.
I am using emacs on a Mac, often with a 4K screen, and generally have no problems. I did have a scrolling lag issue a few months ago, but it was because of a bit of code that I had added to my modeline that was doing way too much work every time something changed in the buffer. The profiler pointed me right to it.
I've recently had to dump Emacs for Vim. I found with using Rust Analyzer on Emacs, it would regularly lock up for a number of seconds. With Vim (NeoVim anyway) this does not occur.
Likely an OSX user. Emacs on my 2018 MBP is noticeably slower than my 2016 Dell XPS running Linux - despite the MBP having more ram, more clocks, and more cores.
Yeah. I still use Emacs for actual development sometimes, but it's been less and less, honestly. But it isn't going anywhere as my git porcelain. I used to scoff at even the concept of a git porcelain- I never used my IDEs' tools to do git ops because I thought they were weird, leaky abstractions, and that you just have to learn "real" git anyway. But Magit doesn't hide git from you- it's just a really nice, interactive, interface over git.
Even better when you can actually hop into conflicted files and use smerge and language-specific tooling (LSP) to do "real IDE" stuff.
I have, on macOS, and somehow, it has much much worse lag than Mitsuharu Yamamoto's Emacs "Mac port," [1] which is still based on Emacs 27.2. The native comp version was so slow that I gave up and switched back to Mitsuharu's port, which is snappy enough for my needs even without the native compilation bits.
From what I gather, mainline Emacs was adversely impacted by changes in Mojave. [2][3] The end result, for me, is that any gains in the native compilation are swamped by the macOS issues. I'm hoping that Mistuharu rebases his work on the native-comp Emacs soon, so that I can get the best of both.
What’s your setup like? I’ve experienced some lagging from time to time—almost always because I turned on some package I didn’t need. My thirst for responsiveness has won out and now it’s nice and snappy.
I’m personally not running the native-comp branch, but I hear lots of people say it’s a game changer. Native-comp recently got merged to master, so when Emacs 28 ships it should be available to everyone!
Likewise with VSCode, Edamagit is very close but isn't "muscle memory" close. I run into things that aren't quite the same as the original: choosing a remote on a new repository when pushing or selecting switches using the VSCode native pop-up.
I really want Edamagit to work. I'm still getting my feet wet with VSCode but Git integration is a bit of a pain.
They could have solved this with porting from single-threaded Emacs Lisp to Guile[1] or a proper Common Lisp[2]. Sadly, both initiatives didn't get enough steam. Someone, though, started to rewrite Climacs in SBCL from scratch[3].
I'm not convinced that Elisp-the-language is really the limiting factor. I'm not an expert on the details- just a passive observer for several years. But, IIRC, Elisp recently got some kind of cooperative async stuff. Even before that, my understanding was that there are a lot of legacy architecture issues with Emacs, from its GUI model to the actual text data structures, that contribute to to latency/slowness.
I think a full rewrite in any language would have likely brought about a better UI experience.
Can you try `lsp-doctor` and try to resolve any performance hints it outputs? The latest `lsp-doctor` seems to also know about the native compiler, so one less thing to worry about when checking.
I've been considering trying to replicate magit in a tui. I'm not sure if I should go for a straight port (many people might find useful, eventually) or change lots of things to make it fit my workflow (might be more likely to "finish" if I optimized for me).
My dream git workflow is rebase-first, i.e. you have multiple WIP commits at any given time, and can send an unstaged hunk to any of them with the same level of complexity.
Those look interesting. If I understand them right they've for mailinglist-based dev where you email patches around?
I prefer a model where you use a forge for collaboration, and don't rewrite shared history. However, you use rebase extensively locally.
Right now I use magit with fixup. It's just more keystrokes. I want to be able to highlight a change to the workdir, hit a key and select a local commit (right now it's highlight, hit the fixup shortcut, select the commit, open a rebase at the appropriate early commit, complete the rebase). I also want to be able to partially stage a newly created file (right now it's cut and paste part of it into a temp file)
I just discovered today that intellij has the concept of named changesets (i.e multiple staging areas, and you select 1+ to commit). I like it, but I don't think you can check them out and they don't work with external git commands. My temp commits would just be regular commits prefixes with "wip: "
> If I understand them right they've for mailinglist-based dev where you email patches around?
You're right, but I think they are not limited to it. Stgit has a command to directly convert patches to commits. Quilt deals only with patches. So the patches will have to be applied to working tree before they can be committed.
> I want to be able to highlight a change to the workdir, hit a key and select a local commit
> I just discovered today that intellij has the concept of named changesets (i.e multiple staging areas, and you select 1+ to commit).
I am still learning stgit, but I think this is what stacked patches essentially achieve. The patches can effectively be used as multiple staging areas. You can design multiple commits simultaneously and commit them independently. Here is my novice assessment of that workflow: https://gitlab.com/-/snippets/2126398
> I also want to be able to partially stage a newly created file (right now it's cut and paste part of it into a temp file)
That sounds like interactive staging (`git add -p` or `git add -i`). You can do the same in magit, in the status window by selecting the diff lines you want to stage. I use evil-mode and use visual mode for that selection. Am I missing something about your requirement?
> That sounds like interactive staging (`git add -p` or `git add -i`). You can do the same in magit, in the status window by selecting the diff lines you want to stage. I use evil-mode and use visual mode for that selection. Am I missing something about your requirement?
At least in magit, you get the error "new file ... depends on old contents" if you try to stage a hunk of a newly created file.
(i.e. echo "foo\nbar" > file, then stage only "bar")
I find magit cool, but I always find myself going back to using tig or !tig (combined with git add -p for interactive adding) inside of vim. It's a lot faster of all the editor extensions for me.
I had some performance issues with Magit (and git in general) under Windows, but ultimately resolved them. I documented the solutions here: https://news.ycombinator.com/item?id=26736006. Maybe some of it will work for your case.
Not to detract from Jonas's efforts in the slightest, but the original author, Marius Vollmer, deserves a lot of credit for coming up with the UI for magit. There weren't any other emacs packages quite like it at the time.
When I switched to emacs, I thought org-mode and repl integration would be the killer features. I was wrong- Magit is best emacs feature by far.
It’s great that parts of the magit experience have been separated into packages. Perhaps now mercurial, perforce etc can get clients similar to magit in quality.
I was reading the thread and replied to a very similar situation. The only addition was that if you want only a magit interface, it makes no sense to load the rest of your emacs config, so you could add a special magit initialization file, and just add -Q --load magit-init.el
I would strongly recommend first doing some emacs tutorials -- you don't have to start using emacs as your editor, but (in my opinion) magit does assume you have some understanding of how emacs works.
Honestly, you'd only get a fraction of the power of magit doing it that way. It's power is due to it being thoroughly integrated into the environment you use for editing all kinds of text every single day. Imagine being able to control git using the same commands your used to in whatever text editor you use.
Magit is incredible and Emacs is my main Editor. Reading the post a couple days ago on text selection and how hard it is to get right makes me even more in awe of what a text editor does
Magit hits the sweet spot between flexible and easy that makes it an actually useful git editor integration. You still need to know git to use it, though!
Just a trivia info (I guess that's how it's called?) - especially interesting for mathematics lovers: the creator of Magit is Jonas Bernoulli, from Basel. Probably a descendant of the famous Bernoullis https://en.wikipedia.org/wiki/Bernoulli_family
I haven't tried very hard yet, but magic has been fairly unintuitive for me. Perhaps it's just that I've been using git for so long.
There have been several times that I tried something with magit, and messed things up enough that I just dropped into a shell and did everything with the git command line
It looks a bit like a menu-based GUI, so you'd expect to navigate around and use a standard set of keys, but most of it is actually powered by special key combinations.
Now, in some circumstances, that works fine, but honestly the interface could be simplified a bit and probably made faster to use. And less prone to the "oh shit, I thought I was typing something but now I actually hit 3 different Magit key combinations and have no clue what just happened".
Personally, I'm hoping someone takes the standard VC thing in Emacs and adds some of the Magit features to that. But meanwhile, I'm using Magit. :)
There's definitely some aspects of it which I struggle with. Like cherry picking a commit always feels somewhat painful, and I can never remember offhand the exact menus and keys to press to do it. But for day to day development, it's fast and great. I love having the separation between the push branch and merge branches for example, which feels very natural in a PR workflow. And the forge integration is brilliant.
Cherry-picking is amazing with magit. I use spacemacs so my magit has evil style keybindings.
I just open up a log view to the branch i'm cherry-picking from, move the cursor to the commit I want to pick, then if I don't remember what the key is I just press ? and it shows me all the commands, then I press A for cherry-picking, and it immediately populates it with the commit that my cursor is on in the log view. Easy-peasy.
I think it's having to go into a log view that bugs me. I just want to press one button for cherry pick, point it to a ref and be done. It might be possible but I haven't figured out how yet.
Yours has been literally the first negative comment out of hundreds of comments I've read about magit. It'd be interesting to learn what didn't work for you and why.
I didn't like it, I have several friends who tried it and didn't like it. The main problem (for us) was that people said "Hey, this is so great you should use it even if you don't use emacs".
This is (in my opinion) terrible advice, as you need to be a fairly competent emacs users to use magit, else you will keep hitting weird situations you can unable to escape (as you don't know the emacs thing to do).
Cherry pick is faster and easier for me in the CLI. I’ve read Magit’s documentation on Cherry pick dozens of times and I still have no idea what it’s doing. I think I have successfully done it in magit once, but now I don’t bother and just do it on the command line.
For everything else I absolutely love magit. The ability to stage and commit chunks in a visual fashion is an unbeatable killer feature!
The first odd thing is that magit runs in emacs' working directory, rather than the directory of the buffer you launch it in (my experience with most emacs commands is that they will take the cwd from the buffer). I'm going to have multiple git repos, and I usually only start emacs once, so this gets me almost every single time.
The submenus are also a bit overwhelming. I just wanted to stash my working tree, not be given dozens of options for how to stash! Emacs already has a way to signal that you want to give an option to a command, so this interface feels very un-emacsy. "M-x magit-stash" should just do the common thing imo. C-u M-- prefix if I want something fancy.
Another time, I fat-fingered a branching operation, and I spent a good five minutes trying to figure out how to fix it within magit, and then gave up and solved it in 30s from the cli
My experience is the same. Probably because I'm so used to git on the command-line already magit doesn't seem much benefit.
I just gave it a try:
magit-blame seems hard to read, I guess it's a limitation of emacs, or can it be configured to show the author name on the left of the line like CLI git blame?
I tried to find the equivalent of "git add --patch", but did not find it in the info manual.
> magit-blame seems hard to read, I guess it's a limitation of emacs, or can it be configured to show the author name on the left of the line like CLI git blame?
There are different styles available. While blaming a file, press B to open the popup, then c to cycle through them.
> I tried to find the equivalent of "git add --patch", but did not find it in the info manual.
That's just the entire staging workflow.
You see a list of changed files, which you can stage per file. Or you can expand a file to its changed chunks using TAB, then stage chunk by chunk. Or you can select some lines in the chunk and stage only those.
I've had the same experience. I've been using org-mode as my primary note-taking tool for several months now and am getting more comfortable with emacs as a result, but while I can see the appeal of magit, the "spend time learning how emacs git" vs "use the CLI to do what I want in 3 s" hasn't balanced out yet in magit's favor. At some point I'll probably sit down and take like a half day or so to actually learn magit, but git CLI isn't really broken for me so the drive to learn an alternative git tool hasn't been all that strong. Still, magit seems nice, so one of these days I'll probably make the effort.
How often do you guys do really crazy stuff with git? I do some rebasing (interactively and not) and some cherry picking, very rarely do I touch reflog (in which case I do use the CLI).
What kind of race car stuff does git CLI offer that makes you have to go through weird contortions in magit :)?
Well to use magit, first it's "ah, how do I open magit again?" Then it's "crap, now my org-mode buffer has been replaced by magit when I really wanted it in a separate tab but forgot to do the right key combo for that", then 5 minutes of googling "how to go back to previous screen in emacs doom", then remembering it's called a "buffer" That kind of stuff. I still get thrown off a surprising number of time by fat-fingering something and my emacs doing something surprising that I don't understand and am not sure what keys I touched to make it do that, and being unable to go back easily.
So it's really 100% on me for not being an emacs native rather than any shortcoming of magit per se, and as I said at some point I'll probably invest the time, but I _already_ have muscle memory for working in my terminal.
Hang in there. I was a beginner at magit (and emacs, to boot) and had to keep at it for a few weeks before it became intuitive for me. I also had to google how to push and fetch and revert every time, because I would keep forgetting it. And emacs keybindings was weird to me at the time, since I was used to vim keybindings.
Just practice, practice, practice. I can attest that the benefits are worth your while (if you use git daily, at least).
> I just dropped into a shell and did everything with the git command line
Note that you can run raw git commands by pressing : in any magit buffer. It opens a commandline prepopulated with `git `, so you can type whatever you want afterwards. The output will appear in the relevant `magit-process` buffer.
(The choice of : is analogous to M-: which will execute an Emacs Lisp expression)
You are probably using melpa instead of melpa stable (like most, I assume). In melpa, all packages use the yyyymmdd.x type of versioning. In melpa stable packages use semver.
Makes sense. I'm lucky no one asks me git questions: the few friends I have that use git know it much better than I do; most of my friends and all of my family don't use git at all.
Magit is designed for people who are already used to the git command line. Sourcetree is not.
Sourcetree is mouse-oriented, and to me it has the same disadvantages as all git GUI clients: I'm never quite sure what it's doing behind the scenes, and it cannot quite do everything useful that command line git can do.
Magit is keyboard-centric like emacs. Yes, so is the command line but Magit relies on individual keystrokes rather than typing in a line of commands and hitting <return>. The result is that once you get used to Magit you can fly through git operations and it's almost always quite clear what git operations Magit is doing. There are still a few exotic command line git operations Magit won't do but I almost never need them.
Magit is like using the terminal client but easier. You have to press fewer keys to do things, and it makes the various operations discoverable through menus. It's really the best way to interact with git IMO. However, if you don't use Emacs already it's a little much to setup Emacs just to use Magit.
SourceTree is terrible IMO. I've had to help so many coworkers (who don't want to learn proper terminal git) unfuck their local repos after SourceTree did god knows what to it. Other git GUIs like Fork or Git Tower never caused these same issues in my experience. If you are currently using SourceTree I would recommend trying this instead: https://git-fork.com/
It's in a different league. Hard to explain to a non-emacs user, though. Which is a tragedy because I'd love to explain, but some things just have to experienced.
This Magit update is not renaming branches or telling you what branch name to use. Quite the opposite. It's a switch from assuming everyone uses only one of the many conventions out there, to having out-of-the-box support for all the major ones.
Tried it once. It seemed cute. That lasted precisely up to the point where I did a "git rebase -i" and landed in some crazy custom mode where I was supposed to use... I dunno, secret keybindings or something instead of just reordering the patches like I've done for years and years.
It went right in the trash and I haven't looked back. Do. Not. Break. Workflows. Ever. If a user knows they're supposed to open a file in a specific format in their editor, and you inject your pixie dust into the guts of their editor thinking you know better what they want to do than they do, then all you've done is prove to the user that you cannot be trusted to support their work.
Seriously: I don't use magit and don't want to learn its new tooling because I don't trust it not to break itself.
