That would require a MAJOR MAJOR[1] version number increment because this change would break so much.
Looking at Git as it is now, I find it very unlikely to see a clean CLI in the nearest timeframe. Changes will happen (if they will) at a very slow pace.
I'm not saying they should change the `git` itself. They could go with `git2`, `giit` or whatever else and just use new interface for common backend code.
A number of reasons: Writing your own means dealing with changing internal behaviour. It means following changing output. It means not being able to reuse parts that already exist but are not exposed. It means deploying separate software where you don't necessarily have root/install rights.
Even if the interface you see as a user doesn't change, the internals do - for example submodules handling has been changed from a standard git dir to git file with directory link. This broke some of my scripts that made git interaction easier.
I don't want to slap something on top of git and hope that there are no edge cases in state/output parsing. I want an actual first-class interface that has at least a bit of consistency between commands.
As you can see, I went that way and it's not usable long-term.
I don't buy this. Give me some concrete examples of how internals need to change. I have lot of git scripts which work off git plumbing and they didn't require any of what you mention. You just sound like an armchair critic otherwise.
I gave one example already. The implementation of submodule .git directory changed (git-file instead of a directory). The change meant I had to check the git version and have two different ways of doing the same thing or the interface I wrote failed.
"""As of git version 1.7.3.1, git status doesn't say anything about the rebase status.""" - so you're left with "does some file under .git exist" approach. It's unlikely to change, but I don't believe it's part of any external interface - when it changes in the future, it changes.
What does MAJOR MAJOR mean? I can't find it in the semver spec. They've changed the major version number - doesn't that mean they can change the API in any way they like?
MAJOR MAJOR is my very own invention and me being overly snarky. What I meant by that is that changing the CLI is a huge breaking change, and incrementing just the MAJOR component will not reflect the hugeness of what has happened.
Looking at Git as it is now, I find it very unlikely to see a clean CLI in the nearest timeframe. Changes will happen (if they will) at a very slow pace.
[1]: http://semver.org/