Anyone who has been in the field understands that for all it's tradeoffs git is an incredible breath of fresh air from systems like CVS/SVN.
That's not an argument. Especially vis a vis the detailed reasoning behind gitless. In my view gitless has a superior experience without losing any power.
Also no one is comparing git to CVS/SVN. It can stand miles above these and still have severe usability flaws.
And I don't work with programmers.
Now, if you have some legitimate gripes about git's usability I'd love to respond to them and have a real discussion, but Gitless doesn't make those arguments, it's just a wrapper around git (which could all be done with aliases) that adds an additional layer of abstraction for no benefit (or at least none that they've felt confident mentioning)
It being "just a wrapper around git" is an excellent argument that the user interface and usability are problematic. Nobody is arguing with the mathematical model underlying git. Gitless manages to expose a lot less state by default. That's a usability win. It's still there when you need it. There is no expressiveness lost. I find the examples they give on their website very persuasive:
If you want the detailed analysis of weaknesses of git that led to the design of gitless, it's here:
https://people.csail.mit.edu/sperezde/onward13.pdf
I don't necessarily agree with everything in there but I think it's an excellent analysis overall and worth reading as a case study anyways.
In my workflow I also see no cost, but I am happy to accept that that's because we don't have very sophisticated needs.
This is generally where I point people who have a technical background
It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.
Our expectations of how we interact with software have risen over the years, and that's a good thing.
It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it has become ubiquitous and now we all have to live with it, programmers or not.
In my view, git has too much state. The state of my directory, the state of my branch, the staging area, the stash, etc.. these all interact in non-trivial ways when merging/branching. Gitless shows that it can be done with less state.
And the design of the interface _is_ atrocious:
http://stevelosh.com/blog/2013/04/git-koans/