Hacker News Reader

Comment by belltaco | Hacker News Reader

Why is git the hardest to grok for most developers compared to almost anything else in the web dev ecosystem? It always feels like a tool with very less or very leaky abstractions.

Is it because the complexity is really needed, or if papering over them and making it user friendly has failed? For example, you won't find a cheat sheet of SQL commands submitted and upvoted so many times on HN, even though SQL implementation and internals are very complicated. Reason being it's able to hide the implementation details and abstract it away.

At the very least the terminology in git is very confusing. Especially 'checkout' for people who came from a SVN/CVS background.

View on HN

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.

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.

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.

It's not just a leaky abstraction, there is no abstraction!

It's the opposite of user-centric design, like a car with no body where you adjust the gasoline pump, the transmission, the amount of oil etc. yourself.

There's an underlying model, which is tricky but not rocket science - and all actions on that model can have a bunch of non-obvious state changes and side-effects.

It's just complicated enough that it's hard to keep track of the models+statefullness without some expertise, experience and thought.

The first time I saw an 'animation' of what was going on with various commands, it blew my mind how much I learned as I saw things happening.

The language we uses is often not very specific and leaves out important details.

We use it because there's a kind of simple brilliance to the underlying model, it's very fast, very robust, and works well for open source.

That said, I wish there was a git optimized for teams and with better abstraction.

Could you please post links to those animations? They could be hugely useful.

Seconded, I would also like to see those animations.

I'm still in camp subversion, my main gripe about git is the lack of a linear rev number for master. The rest of it is complexity you can either take or leave.

I've thought about writing a subversion compatibility scripts overlay for git, just to make my live easier.

> my main gripe about git is the lack of a linear rev number for master

Unless you are using git as a centralised SCM, the concept of a linear revision doesn't quite match up.

Of course many workflows between different branch and people do eventually end up with there being a "master master" (or a main main to use more up-to-date terminology), and workflows for single dev projects naturally do, perhaps in those cases you could wrap relevant git commands in something that increments a build number stored in a file before relevent actions.

It perhaps do away with a simple increasing revision number and use the date of merge on that branch, which would at least always be increasing.

Most people are using git in a centralized fashion whether they realize it or not.

That is a very correct point.

Though it isn't git's failing when people use a distributed SCM in a centralised manner and expect it to be optimised as such!

You took the words out of my mouth.

They're using git with Gitea or Github, or Gitlab, there is a defacto centralized master.

git rev-list --count ${GIT_HASH}

Is it because of trying to use too many features? Or working with large groups and everyone trying to do too much?

I've been through 3 source control systems now, and Git is by far the easiest. I only branch, clone/init/add/commit/push/pull and merge. (And now most through the gui in vscode) There are some minor fixes I've had to look up, but it's rare.

Almost all the complaints I hear about are from very obscure commands and situations I've never seen.

Is using Git in a simple way the answer to everyone's problems with it?

Using Git only in a simple way isn't quite the answer to problems, because if you make a mistake, you'll still need to use non-simple commands to get yourself out of it.

When my level of understanding of git was "add/commit/push/pull", if ever I made a mistake, I'd then have to try a more sophisticated command which would then risk making another mistake.

At one point you'll have a long-living feature branch which you'll have to periodically rebase with the main branch, and this is where nightmares begin.

Reply on news.ycombinator.com