I feel like this is just another "git is hard so lets make it easier" program that makes collaborative development a pain. maybe its just my puritan work ethic.
first we had git, and anyone who cared to spend the time could pick it up and understand it well enough to use it. Then we got github and gitlab, which made remote branches more manageable but introduced and entirely new class of developers who only added code through the web interface and emailed/called when they needed a merge or just merged to master because you were sick of the hand-holding.
then we got the GUI clients for windows, which resulted in armies of programmers who didnt understand keys, or authentication, or why the gitlab/github server existed but just wanted to commit their code and as a result left the codebase with a graveyard of rebase --hard and reset head garbage that had to be explained later. supporting them became a nightmare of screen sharing and shouting.
finally we have gitless? and developers now have to keep straight gui, console, gitlab/hub and some asinine wrapper script between the teams? so when jack commits with his GUI and accidentally drags and drops 3 branches, while jills gitless command wiped half the unprotected master, how does it get sorted out?
Git was not first, and it arguably didn't achieve its dominance based on technical superiority. It almost certainly didn't achieve that dominance based on offering a better learning curve or a bizarre interface choice, even though I might personally understand and appreciate the relative tightness to its underlying systems. I also don't think we should defend a technology or tool by portraying it as a sort of null-hypothesis, a default automatically suitable for anyone except in special circumstances.
I'm currently making source control recommendations for my new client. No one there is a full-time programmer, and they mostly do engineering and PLC work, but more recently they have to work with higher level languages from time to time. They absolutely need something they won't have to fight to learn. Other times I've recommended source control during my career include tutoring first-year/some second-year university students, who are often still only becoming familiar with programming and CLIs, and for whom Git seems both arcane and stress-inducing, two things you absolutely don't want from a source-control system.
I am adamant that in neither of these above cases would git be the right choice. I'm also not convinced its the right choice for many development companies, which often have staff of a range of skill levels. I'm lucky in that I've nearly always been working with passionate programmers, where we can and do happily make the choice to adopt git without a second thought.
Git did beat both of the other main contenders in the DVCS space (Darcs, Mercurial) hands down when it came to performance around the time it rose to prominence, so I think it's unfair to say that it had no technical superiority.
"Didn't achieve its dominance based on technical superiority" - I partially disagree. Compared to SVN, Git was superior in multiple aspects. Perhaps it was not The VCS To End All VCSs, but lacked the annoying warts of CVS and SVN. (Mercurial does have some nice features, sure - but wasn't quite there when Git was on the up-and-up)
Funnily enough your complaints also completely ignore what gitless actually is. It does not hide the underlying git structure, it just exposes it in a sane way. Check out the research papers. It's really well thought out. Same power with less exposed state is to me the definition of good software design.
I don't teach gitless to novices because all the rest of git tooling uses the original git vocab. Unfortunately we seem to be locked into using the bad interface design of the original git forever and ever, along with the chorus of people who claim it's perfectly intuitive (once you spent a few thousand hours debugging user errors).
first we had git, and anyone who cared to spend the time could pick it up and understand it well enough to use it. Then we got github and gitlab, which made remote branches more manageable but introduced and entirely new class of developers who only added code through the web interface and emailed/called when they needed a merge or just merged to master because you were sick of the hand-holding.
then we got the GUI clients for windows, which resulted in armies of programmers who didnt understand keys, or authentication, or why the gitlab/github server existed but just wanted to commit their code and as a result left the codebase with a graveyard of rebase --hard and reset head garbage that had to be explained later. supporting them became a nightmare of screen sharing and shouting.
finally we have gitless? and developers now have to keep straight gui, console, gitlab/hub and some asinine wrapper script between the teams? so when jack commits with his GUI and accidentally drags and drops 3 branches, while jills gitless command wiped half the unprotected master, how does it get sorted out?