I didn't know how to use a welder just by looking at it, but the UX is fine once you know the concepts behind welding.
I honestly can't see how git could be easier given the requirments of the tool. If you want to reduce its capabilities because it's too hard then go ahead, but please fork it or make something new instead of ruining a perfectly good developer tool.
I do find the division between git seems to be really concise. Either people don't get what the fuss is about or they think git is just the worst.
If you're curious how it can be done (IMO), take a look at https://github.com/martinvonz/jj. It's its own VCS but also compatible with Git so individual developers on a team can migrate to it.
I think for this reason there's a lot less pushback on its bad UX than there would be for any other program. It would render knowledge of its arcane guts less...special. The juniors will be forced to deal.
It makes me wonder though, if needlessly arcane knowledge is and always was a part of other apprentice relationships.
I see a lot of complaints about it, and agree that for all the porcelain, you do have to become familiar with the plumbing to solve issues.
But noones shown me a good alternate ux story, just different porcelain/fittings. I still have to reach under the sink because said new porcelain didn't stop/avoid a case sensitivity clash, or it barfed on a merge and left the repo still to merge.
Mercurial and Git have, for most purposes, functionally identical capabilities. Atlassian at one point allowed you to checkout a project as either a git or a mercurial repo painlessly.
Mercurial's porcelain makes sense: the command is exactly what you think it is, usually without any funky modifying flags. If there are flags, they're often obvious, and if they're not, hg help <command> will clear that right up.
Contrast to git, which is a mishmash of commands and esoteric flags, and the help isn't even inlined.
The underlying concepts are easy enough, but how you access them requires memorization of arbitrary command sets that are inconsistent and overloaded.
Fix the porcelain and IMO you fix most of the problems with Git.
I sure wouldn't call that a _bad_ UX. As with any tool you have to adjust to the tool or make your own unless by some miracle someone shares your particular idiosyncrasies.
>"modifying tool makes it different from your co-workers tool"
Yes, but that is a big plus instead of a minus. If your co-workers asks how to do something you can just give them the content of the alias. I also alias `git` as `g` in my terminal. Is that going to cause problems for my co-workers? No.
Unless you are training a complete-fresh-out-of-school-junior the "new guy" should already know how git works and in either case that sounds like homework for them more than anything else.
In terms of the metaphors for the actual commands, I would agree. Reset and checkout basically make no sense for what they're actually used for. Switch makes things a bit better, but yeah, it would be nice if the entire Git CLI could be redesigned from scratch.
Every tool has its modus operandi, incl. but not limited to every programming language. Extending our understanding is hardly a bad thing.
Git proposes a model for handling stuff, and I prefer it very much.
And yes, the UX is fine.