Visual Git Cheat Sheet

For me it's because it's highly stateful, and in ways that are mostly invisible. You have to keep in your head whatever state your repository is currently in so you know what actions you can/should take next. And if you wander off into a bad state, it can be nearly impossible to chart your way back blind unless you've been there a few times before. It's like playing the world's worst text-based adventure game.

I think the above problems mainly come down to the fact that it should be a GUI but isn't. Which is why so many GUIs are built on top of it, but then they're shaky because they depend on a CLI which is itself trying to be GUI-like. I would honestly take a text-mode GUI over what we have, and I don't even use text-mode GUIs normally.

I always say, git is the worst VCS except for all the other ones.

They didn't include git push?

I immediately liked "git the architecture", but stayed away from it a long time because of what I though a poor user experience. I attributed this to the clunky CLI, but you're right that the richer state was also part of the problem for me when using the CLI. With the index (and also stashes) there's more state than in subversion for example, and it must be managed properly.

Magit (https://magit.vc) solved both problems as far as I'm concerned. It shows the current git state in a clean, easy to explore way. It also makes it easy to change it as needed. It also hides most of the CLI oddities by building commands for you from a well designed menu system --- some weirdness will remain: bypassing hooks is "-n" for a commit and "-h" for a push for example. That's the price of staying close to the CLI. And the result commands can be seen and checked if one wants to. Magit makes the git options visible and discoverable in a compact way, and expressing what to do easier.

To me that made the difference from preferring sticking with subversion or using mercurial, to preferring git today. In particular, the index is a very powerful tool to break a lot of changes in a set of nice "atomic" commits once done. I really appreciate it now that I can easily visualize it and control what's there, and trivially sends specific line changes to it.

Sure, Magit is tied to Emacs. But it's possible to use Emacs just for Magit. I'd recommend anyone having problems with git UX to have a try. Some people may joke that now they have 2 problems, and that may be true ;), but for someone that can deal with the Emacs basics I'm positive Magit will be a plus to deal with git.

The website captures left/right arrow indiscriminately of modifiers, causing short cuts like Alt+Left and Alt+Right to go back/forth in the browser history.

Because unfortunately, network effects, Torvalds' influence and the rise of Github made a tool which is a UI nightmare, and only really makes sense for really advanced users, displace all the alternatives.

And we now have plenty of people who would just need a knife to cut fruit, and are instead cutting their fruit with a surgery-grade remote-controlled high-precision cutting robot, and spending lots of hours learning the fine detail on how to operate such a robot (trying to get by with only 4 or 5 buttons of the hundreds of buttons and knobs in the robot, but often failing and needing to look at the manual to undo their errors), because you need to upload your fruit "surgery-grade-remote-controlled-high-precision-cutting-robot-fruit-hub" if you want it to have visibility.

Hg is much more intuitive and I'd say 90% of git users would be happier in an alternative timeline where it had triumphed. Darn, even SVN was much more intuitive UI wise, even if of course it falls short on functionality these days.