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.
