I guess it’s dependent on project, but IMO if a commit is important enough to be in the main branch, then that should have its own merge request. I like it when all commits in the main branch have gone through all the build pipelines and verification processes.

But if having separate MRs is undesirable, then you could always overrule the squash policy. I know it’s possible on Gitlab at least.

Yeah I agree but in my experience developers seem to struggle with "keep important things in history; squash unimportant things". An open "merges allowed" policy leads to people unthinkingly merging branches with 50 "typo", "fix" commits for a 100 line change.

Dunno what the answer is there.

There is no other CLI tool like Git. But

Shell or Bash has various alternative shells.

Vim has numerous plugins and alternatives/extensions.

Linux distributions are wide and varied, forking out.

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).

Nonetheless

You didn't provided a single concrete example of something you actually feel could be improved.

The most concrete complain you could come up was struggling with remembering commands, again without providing any concrete example or specific.

Why is it so hard for critics to actually point out a specific example of something they feel could be improved? It's always "I've heard someone say that x".

alias fuckit="git add . && git commit -a && git push -f"