The issue with git isn't that it has warts or that it's not improving - it's that it's a cli tool with bad and confusing defaults. Because people use bash for programming, the cli interface is basically an API now. So we can't change it because it would break peoples bash ci/cd scripts. That's why git is bad for humans: because it's kept backwards compatible in order to be good for computers.
I keep arguing that the unix model of using the same api for human consumption as for scripting is broken. One needs to be concise and doesn't need to be backwards compatible (interactive use), the other needs to be descriptive and backwards compatible (sctipting use). Git wasn't designed in the 70's so could easily have avoided this.
Compared to how it would work today if it wasn't constrained by backwards compatibility, and it was designed for ergonomics rather than power. Every time a best practice changes, or a new default is considered best practice, or you notice a typical usage pattern means a particular command is much more common - then the interface should reflect it. There have been multiple wrappers such as this one - but there could be room for a big official cli tool that is not backwards compatible (want to script? - call git directly).
> It's leagues better than what it replaced (SVN & CVS) a
Git as a tool is better than svn and cvs - but I don't agree its interface is. This is of course an unfair comparison since svn, cvs etc is so much simpler (It's after all a LOT easier to make a good UI for a ToDo app than for facebook). The best comparison for an UI of a "modern" vcs is git vs mercurial.
Is a prime example of how, if you designed it from scratch, you wouldn't leave inconsistent. "List things", "delete things" etc are activities that should work the same for all kinds of objects. the Git cli isn't designed with that thought. It's organically grown and every change is more or less irreversible because the human interface UI is used in programming (What I like to think of as the biggest flaw of Unix)
I keep arguing that the unix model of using the same api for human consumption as for scripting is broken. One needs to be concise and doesn't need to be backwards compatible (interactive use), the other needs to be descriptive and backwards compatible (sctipting use). Git wasn't designed in the 70's so could easily have avoided this.