[pydry]

Knowledge of git has become a sort of status signifier. It "makes you a developer".

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.

[tehbeard]

How do you improve the ux though?

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.

[Espressosaurus]

Make it use Hg's CLI.

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.

[xigoi]

Making the CLI self-consistent would be a big improvement.