For a similarly complex task, there is no program with a better UI.

Magit manages to optimize for both, speed and discoverability: 99% of all actions are 2-3 keystrokes away, and at each stage of that process, magit will tell you your options. For example, invoke magit, press 'b' brings up the branching menu, basically a keymap for letter -> action. Pressing 'c' for checkout then starts a new branch creation. The default branchpoint is your current branch. If that is fine, press enter, otherwise type out the branch name (tab completion for all possibilities, local and remote). Finally, you name your branch. So in 99% of the cases, it is b>c>enter>my_cool_new_feature>enter, done.

Before magit, using version control was a necessary evil (for me). Nowadays, it is so effortless, so natural, that it hardly registers in my attention -- similar to the way that you automatically save the file that you are working on after a couple of lines of writing without noticing that you are doing it.

All cli tools should have a magit interface. World peace and happiness would ensue.

:) Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli. That does sound great! There are some git commands which would be super annoying to do via a UI (not to mention if you add _all_ of git's features to a UI, good luck making anything discoverable :P), but in the CLI they're kind of awkward cause unless it's something I use very frequently, I forget the syntax (looking at you git bisect). This sounds like it would make those significantly easier to use, _and_ help the developer discover new git commands they might not be aware of (looking at you, git bisect :P).

It's a complete git "porcelain", in that it provides more or less full access to all git offers.

I daily rewrite git history in my feature-branches, cleaning up my commits, to provide fully atomic and clean merges back into dev.

Using magit, it's just seamless and feels immensly rewarding wrt doing a good job. Without magit? I wouldn't even bother.

Magit is not "just" a wrapper around the git CLI. It's a complete replacement, enabling you to fully exploit all of Git's power without ever leaving your editor of choice, nor exposing you to complex internals.

It's an amazing product, and I've seen people ask for a Magit-only Emacs-distro, just to replace their existing Git client.

The other thing I love about it is discoverability of git features. Did you know that you can stash index and working tree separately? I only know because of magit. Now that I know, I have actually used it to great success.

Also, I've become my team's go-to rebase monkey. What takes my colleagues minutes of thinking what to rebase where, and how, and how to deal with the conflicts, I'm usually done in seconds. Also, conflict resolution with magit is really very streamlined. Conflicts still suck, but less so.

Pushing/pulling to/from different remotes is quick and easy (happens often with github forks and PRs), merging and branching is a breeze, and you've got splendid auto-completion on branch and tag names (I use ivy.)

The blame mode you described exists in magit, too. You can annotate a file and drill back into a certain commit's history. Actually, the default way magit does it is dissimilar from what you might be used to from other GUI tools. Magit doesn't annotate the left or right, but instead inserts header lines for a commit. That way it's easier to see coherent commits. I find this way of displaying history nicer if your code's commit history actually contains chunks of lines for the files, and it's not so fragmented that practically every line is from a different commit/author. It's possible to do the margin-annotation you're used to from other blame tools, too, though.

> Did you know that you can stash index and working tree separately?

What does this mean? Can you give an example?

> Also, I've become my team's go-to rebase monkey.

Haha, hello friend. I love rebasing; it always breaks my heart a little when I see "Merged master into branch X" commits :P My main git rebase flow is `git checkout master; git pull upstream master; git checkout X; git rebase -i master` + vim. Having multiple branches that depend on a shared branch does get a little messy though. How does magit make this flow better?

> Conflicts still suck, but less so.

Hahaha, that's all you can hope for with merge conflicts!

You can stash tracked files with modifications, or tracked files without modifications separately! Scenario: I've staged a couple files for a commit I'm preparing, but I see that there's an unrelated change in the unstaged files that I want to do in a commit that should come first. So I stash everything I've staged. I do not stash what I haven't staged! Now I can create that new commit, and pop the stash later to come back to the commit I wanted to originally write.

And yeah, incremental committing, the rebase workflow, working with multiple remotes... they’re all a breeze. With the GitHub style PR workflow, I typically set the main repo for a project as the “upstream” remote and my fork as “origin.” With the settings I’m used to for a project, pulling down the latest changes from upstream is two keystrokes: “F u”, and pushing back up to my fork is two more: “P p”.