Git is too hard

I get what you are saying, and this makes sense, if you are in a situation where the problem your tool solves is so special and the target audience of your tool so involved that it makes sense to do things differently than the rest of the world.

This is rarely the case. Sometimes at the end you get nothing but a wet handshake. Think about vim: it is cryptic, does everything different than everything else out there , but it gives you something in return.

If you make your tool less inutive, but give users nothing in return, you are doing it wrong. If the interface of your tool does it one way in this corner and another way in that corner — so if you are inconsistent without good reason — you are doing it wrong.

Interfaces are about clear communication. Interfaces are the difference between a rugged 50k$ Arri Alexa cinema camera and a 200$ camcorder: the more Alexa has physical buttons and knobs for important things precisely in the locations where they should be, precisely behaving in the way they are expected. The cheap camcorder has buttons, encoders and levers sprinkled over it seemingly random.

The interface of a tool is good when it can be used intuitively even under stress, in bad weather and on drugs. This is ehat we all should aim for imo: tools that are more powerful/expressive AND more intuitive at the same time.

I like reading manuals, but not for things that could have been totally obvious if somebody spent a split second thinking about how to communicate it clearly.

Why is small frequent commits a good practice? What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed?

Also, cherry is often needed daily in short bursts around releases.

Blame is rarer, absolutely, but I don't think you're using your version control to anywhere near its full potential if you don't use blame (and log) while investigating complex bugs.

Reading TFM and understanding TFM are not the same thing. The more intuitive the design of the system, the closer they are. The point people are trying to make here is that git specifically has an uncomfortably large gap between the two.

While people could put in more effort to learn git more thoroughly, there is validity to the sentiment that git could be easier to learn.

The git plumbing is awesome and robust. The git porcelain (aka the cli UI) is optimized for people that are deeply comfortable with command line tools and setting up aliases for things they do a lot and/or scripting things together. I'm OK with it and I memorized most of the commands and flags I need regularly.

Most experienced developers are used to this. Most other version control systems have similar issues. I started using Git 15 years ago by means of running it against subversion via the git subversion plugin. That forced me to learn a few things in a hurry and made me realize just how limited subversion is. I got into that another five years earlier by migrating a code-base from cvs to subversion. 20 years ago, using cvs was considered acceptable as a version control system. Neither of those were particularly user friendly but they were a lot simpler to use because there was only so much you could do and even less that worked well enough that you should do it (like branching and merging).

Git UIs as attempts to make git user friendly seem to be mostly not very successful. I always struggle how to do even basic things with git in IDEs like Intellij or VS Code because they seem to insist on coming up with their own terminology. I mostly ignore that stuff and do it on the command line. I use a simple mac tool called gitx as a ui for viewing diffs and writing commits. But I push, rebase, merge, etc. from the command line.

Github is the exception. It's awesome as a web based UI. And it's the reason that git became the dominant remaining version control system against a long tail of things like darcs, mercurial, and other decentralized version control systems and an even longer one of legacy/obsolete ones like subversion, cvs, etc.

None of those are any better in terms of UI and at this point basically all of them are magnitudes worse when it comes to being properly integrated into other tools. So, that kind of is why Git 'won' and why the barrier to entry for new tools is very high.

But git could definitely do with a rethink of the porcelain at some point. I think the issue is most of the interesting problems are on the plumbing side and hence most people get stuck in protracted wanking around diffing algorithms rather than actually fixing the UX issues. Techies are just not good at UX. By the time you 'get it' well enough to fix it, it's no longer a problem for you.

I've tried GUI interfaces to git before and I just haven't been satisfied by any of them. They seem to work right until I need to do something out of the norm. I did find git a huge PITA when getting started though but now that I have some muscle memory, I won't be trying anything new any time soon.