Git is already too horrendously complex. At this point, any feature whether worthy or not, has to be weighed against the learning curve required by new git users (already formidable).
Can't even count the number of times that we brought on a reasonably decent programmer, wrote decent working code, but that didn't have a clue about git, which resulted in the work being a mess of commits across multiple branches and forks.
To make git more powerful, the developers should make it easier to learn, not add power-user features.
Totally disagree. The general flow of fork (sometimes?), branch, commit, merge, rebase, and/or squash is ridiculous. Eventually you'll also need to learn stashes, tags, remotes, merge requests, .gitignore, and who knows what. Most engineers just want to get their code into the main working repository. I use git every day, but it comes with so much baggage of vocabulary and ways things can go wrong. I get that git is powerful, it's just far too powerful for the vast majority of projects.
> every single person I’ve met that is either too stupid or too ignorant to learn the basics of using git also writes terrible code.
With git, a beginner programmer struggling to bang out some code now has to learn a whole additional system, just to save and share their code. Now, instead of teaching them on the language/product, you have to spend your time teaching them git. Of course experts know how to use git, but everyone else has to spend a week-plus learning a system that's not directly related to their job responsibilities.
It's somewhat similar to lawyer learning Microsoft word, an accountant with Excel, or teaching a draftsman how to hold a pencil... sure the good ones know how to do this already, but people would move so much faster if they could jump into things faster.
> "It's somewhat similar to lawyer learning Microsoft word, an accountant with Excel, or teaching a draftsman how to hold a pencil... sure the good ones know how to do this already, but people would move so much faster if they could jump into things faster."
Agree. However, the difference being __all__ those (each) have a universal defacto UI. Even when you write code, you see the result.
On the other hand, (CL-based) git requires you keep a bunch of extra stuff in your head. You have to know why questions (read: commands) to ask in order to "see" what's going on, etc.
We live in a UI / UX world. In that context (CL-based) git feels like a fax machine. Couldn't / shouldn't there be something better? If disruption is such a great thing, why does git get a free pass with "this is how we've always done it"?
> why does git get a free pass with "this is how we've always done it"?
I'd argue that the git monoculture is a much more recent phenomenon than we remember, and driven largely by the hegemonic status of GitHub in pop-dev culture. Now the possibility of using varied tools seems remote because everyone wants to be in the same place as everyone else.
Even the way we talk about teaching and onboarding new devs is couched in terms of GitHub, and GitHub alone.
The basic feature set is pretty much the same, and requires similar effort to grok. Some things are much harder to do in Mercurial, and some things are just confusing (multiple heads, pushing branches, multiple branching models, the "tip", etc.). Online platforms are worse (Bitbucket vs Github) in practice.
Can't even count the number of times that we brought on a reasonably decent programmer, wrote decent working code, but that didn't have a clue about git, which resulted in the work being a mess of commits across multiple branches and forks.
To make git more powerful, the developers should make it easier to learn, not add power-user features.