3 ms·

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

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.

yaantc 5y ago
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 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.

yaantc 5y ago

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 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.