> The command line interface doesn't reflect this properly, but it's the underlying model that counts.
Could you explain why, for a tool meant to be used by humans, the underlying model (which I agree is very elegant) counts more than the user interface?
A source code version control system has to be in control of the source code. The model clearly is important to whether git is in reliable control of the source we entrust to it.
Function matters more than anything else... and exactly what "function" means and encompasses can be discussed, but it's difficult to define function such as to exclude git's model from git's function.
In any software program, how you model the data tends to be at the root of all else in the program. If you screw that up and make it complex unnecessarily, you will have an inferior program. You can put a bad UI on a good model, but you cannot expect much stability from any UI on a bad model.
It's just like the movies. You can make a bad movie from a good script, but a bad script never, ever made a good movie.
the underlying model (which I agree is very elegant) counts more than the user interface?
It does not. But git exposes this all the time, so committed git users feel that's a good thing, because understanding it makes helps them to make sense of some of the worst parts of the UX.
Git is the reference implementation of a protocol, and much like HTTP, you must learn it the hard way if you intend to be a professional in the domain.
The mistake is to believe there is a U<I|X> in the first place.
It does not, however, stop you from using one of the many graphical tools, that are fine for simple usage and will all eventually fall short.
You could use a GUI to make complex HTTP routes, through proxies and DNS records via drag&drop, and then one day you'll have some weird DNSSEC error that the maintainer does not care about, and you will have to explain that to whoever is losing money.
Acknowledging a problem is not as trivial as it was first thought is critical in our line of work in my opinion.
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.
Could you explain why, for a tool meant to be used by humans, the underlying model (which I agree is very elegant) counts more than the user interface?