In reality this "reference implementation" is the sole interface 99% of the users use, so the lack of UX is an issue.
There are other tools that do it better and right, so insisting that there's any redeeming qualities to git here is being blind to the obvious. There's actual academic research describing git's problems here, for crying out loud.
> There's actual academic research describing git's problems here, for crying out loud.
And interestingly, all the academic research talks about is the high level UI. Not the underlying data model.
> In reality this "reference implementation" is the sole interface 99% of the users use
/That/ is the mystery to me. I don't see a reason why a better UX around the same underlying data model, talking to the same server (and thus interacting natively with e.g. github) hasn't picked up.
Heck, one could implement mercurial's UX on top of the git data model. In fact, that even has been prototyped. I can't find the repository anymore, but iirc it was somewhere on bitbucket.
There are at least five such front ends (easygit comes to mind) and extensions (like legit from Kenneth Reitz). But none is popular, and I suspect the reason is that, despite all the complaining, Git's default UI is not actually that bad in day to day use.
In reality this "reference implementation" is the sole interface 99% of the users use, so the lack of UX is an issue.
There are other tools that do it better and right, so insisting that there's any redeeming qualities to git here is being blind to the obvious. There's actual academic research describing git's problems here, for crying out loud.