yea this all generally tracks.

The kind of “polish” I’m talking about is the sort that a good UI/UX/GUI dev would do by tracking common user behaviours and needs or having testing users run the app through its paces. All of these confusing instances where better terminology, commands and error messages would come up through a process like that.

Now, one could say that this is a dev tool which shouldn’t need to go through that process. That developers should be expected to understand the tool’s inner workings and conceptual model well enough to not need any of that. But that gets back to my initial point. Git is so popular and basically ubiquitous now that that policy makes little sense. Many devs who use or are expected to use git are not capable of getting to terms with git’s internals to the point of never having difficulty with the UI, either because of a lack of time, capacity or skill. Moreover, the time required to get familiar with git enough to never find the UI frustrating should not be underestimated … it’s not just conceptual but technical and specific to git’s implementation details to the point of just knowing how the UI/CLI has been implemented.

If you want to trash such developers … go ahead … but they’re still developer’s doing work and it’s to the industry’s benefit to have a standardised and powerful VCS … which means that at some point it’s worth thinking about meeting developers where they are.

Beyond all of that … one could also say “fuck that” and talk about how being popular and “the standard” requires being better. Git’s centrality to the dev workflow as at text-editor levels. But while text editors have a portable format (IE “plain text” and character encodings) and so enjoy pretty healthy competition (vim, emacs, sublime, VSCode, Jetbrains … etc) … VCSs, AFAICT, don’t have the same portability and neither the competition. I’m actually curious now … are there drop in replacements for git that provide complete compatibility but are completely different implementations?.

It’s interesting, IMO, to think about why/how this has come to be, but in the end, it means that there’s a lot on git’s shoulders here. Even a little bit of an improvement can go a long way, and so being critical (rather than cultishly defensive), I’d argue, is the correct aspect here on utilitarian grounds.

As for why git is in its current situation (without having really thought about it before) … I’d actually speculate that there’s something insidious here regarding it’s imperfect/confusing UI. Namely that it has a monopolising force. Once it’s gained critical mass, and once there are enough devs out there who have deep and experienced understanding of the tool, and enough internet content capturing that expertise, then moving off to another tool which doesn’t have the same established expertise is prohibitively difficult. Comparing here VCS to text editing and programming languages may be part of it, where the basic difficulty of doing VCS (at least in so far as the complexity is exposed to the user) is likely somewhere between that of a text-editor and a programming language. In a similar vein, the solution space for VCSs is probably relatively small while text-editors and languages enjoy a good deal of design variety. And so, there’s little interest or inventive or even capacity to come up with interesting alternatives for what is a relatively difficult/complex kind of tool, which gives any established VCS a good amount of competitive protection and inertia.

Keep in mind though, I’m not talking about the UI here, but the core functionality. That many GUIs exist shows that the UI is a relatively open design space. But that git itself has hardly explored that space on their own is my critique (where comparing to text editors like vim/nvim and emacs and the built-in features they have might be informative here).