Unfortunately, it is still very easy to lose data, e.g. by trying to undo a temporary commit with `git reset --hard HEAD^` (note the --hard option) before committing your changes.
It's the same reason consumer operating systems have a trash can and undo features. Just railing on people with "you should've known better" doesn't really help.
The manufacturer of the machine won't be responsible for sure if you didn't even read the manual… Clear case.
That's reality in engineering.
If developers want to call themself "engineers" they should behave as such.
On the other side you don't let people without special training even close to industrial machines! The risk they could get killed by an accident is just to high.
Here lies the discrepancy actually: "Software industry" is as much an industry as running a kindergarten is. Also there is the most time no "engineering" at all in "software engineering"… Just trail and error until "something works" (or at least looks on the surface like it would, no matter how broken it is on the inside).
As long as people are supposed to "learn on the job", and there are no clear quality / security standards in this "industry", and stuff is called "engineering" even no true engineering approaches are followed, nothing will change. Machines will continue to kill people in completely avoidable accidents (virtually)…
But that's in my opinion a fully homemade misery actually.
It is not a different league it is a different sport. If a factory was designed with the equivalent of gits usabilty today, it wouldn't even get a permission to be built based on the plans alone. Also the person who planned it would have a hard time ever doing so again.
If git was a bridge it would have no handrails and it would oscillate in certain winds and for some odd reason there is a roundabout in the middle.
It is still better than no bridge for sure. As one of the first of its kind a lot can be excused, but fundamentally better engineering is possible as well.
The only single-operator machine I can think of which has an interface even 1/10th as complex as git is an automobile. The number of fatal accidents that could be remedied by reading the manual is vanishingly small.
Documenting poor design rather than improving it is lazy, bad engineering. Requiring rote learning of an very complex interface that poorly represents a moderately complex data structure is lazy, bad engineering. Macho, hyperbolic, gatekeeping arguments for non-design as a design philosophy is advocating for bad engineering. Being mad that people want products with interfaces that make sense is being mad that people want an important facet of good engineering.
We are discussing designing the machine in a way that removes these options altogether.
This is objectively and obviously a better strategy because humans are fallible, even when well trained, and the time put into safety training can now be put into an actually productive direction.
You're working from the perspective that machines and git must be dangerous to be effective. This is an assumption that should be challenged before the enormous waste of safety training is accepted.
When I started web dev, I earned $15/hr. Beat the $8/hr I was making before that in landscaping. Now I make a little more than that, which still isn't much. My clients/employers don't pay crazy wages and they don't expect crazy quality work. They know they get what they pay for, and it works out for both parties.
Maybe's OK to have shitty, mediocre code for 90% of the world's needs... a small biz website, with the ecommerce/PCI bits outsourced? Sure, why not. It mostly works, and if it goes down for a few hours a year, maybe that doesn't meet super-reliability standards (can we count 8s instead of 9s?) but it gets the job done well enough? Shrug.
Sure, proper engineer techniques matter for certain applications. I would never want to touch industrial machines, or medical, or space, or automobiles... anything that could blow up and/or kill someone. But most code out there is just for some local, small-scale use, mostly temporary anyhow and bound to obsolete in a few years if not months. There will always be mediocre businesses needing mediocre devs for mediocre pay, just as there will be elite enterprises that require the world's smartest people.
Problem is, git was designed by the super smart for the super smart, great engineering with terrible UX. And it was kinda just trickled down to the rest of us, and it feels a bit like trying to teach Mom to use DOS and edit config.sys just to play a game. Now consumer software UX has leaped forward by decades and it shows, but a lot of the command-line dev tools are still incredibly arcane. They don't have to be, but it's not a priority to fix/improve their UX because, I suppose, it's engineers who are proud of their engineering, not proud of their ability to dumb it down for the rest of us. I don't blame them, I just know I can't meaningfully contribute to git (the project) because I'm not smart enough, well trained enough, whatever, and that complaints would fall on deaf ears like yours. It's an altogether different culture. Elitist by design, or meritocratic if you will.
And believe or not, I've probably spent more time learning git -- reading documentation, diagramming it out with coworkers, cloning repos and experimenting with commands, etc., following a shit-ton of tutorials -- than any other skill I've ever had to learn. It was quicker to learn Perl and regex than mid-level git.
If you want to pay for the world's would-be engineers to receive all the training to go from mere dev to proper "software engineers", by all means please do. But otherwise, well... you know what? World's gonna keep producing mediocrity. Most of us are just average.
Also, git reset ---hard HEAD^ deletes nothing. The commit HEAD was pointing is not deleted. You have to work really hard to delete that commit accidentally
If you type in "rm -rf ." there will also be no "warning" about what happens next…
I for my part don't like systems that after giving it a command very explicitly asks me whether it should really execute that command. "You just pressed the button to delete those files. Do you really want to delete those files?" "Oh, no sorry. I'm the operator of this system but I press buttons randomly just for fun. Actually I have no clue what I'm doing. Thanks for that pointer! Please ask me also the next time, as I'm not going to remember what this button does. In fact I have no clue at all what I'm doing." Dude…
Git is not a backup tool. (Even you could use it as such).
If you need a backup, make a backup.
I'm aware of the fact this this comment may sound impolite to some. But out of my perspective it's a feature and not a bug that unixy systems traditionally don't ask stupid questions after you told them to do something. It's an attitude of respect towards the operator: The system assumes that the operator knows what he is doing. Asking questions in the style of "do you really, really want me to do what you just said" is on the other hands side just extremely rude against the operator—as the systems assumes the persons in front of the keyboard does not know what he is doing at all! I hate systems with build in "support wheels". The creators of such systems obviously thinks their users are cretins, and that's very annoying.
Well, that's the purpose or "reset --hard". "reset" alone doesn't do that. That's the difference with "rm". With "rm" you expect something to be removed. "rm" may fail because you gave it a directory but you forgot "-r". Or it may fail because you don't have the right to the parent directory or something. But it is pretty much expected that something will be deleted if you run "rm".
From the perspective of people who don't understand the difference between "git reset", "git reset --hard", etc., that some of those will destroy their data but not others, is part of the confusion. And when they picked one instead of the other and lose their modifications, they'll blame git from being confusing to use, not themselves for not doing a backup before running a command in their source directory with a program that is used to manage source directories.
By the way, have you ever run across a situation where the standardized behaviour of rm without -f (to wit, check the permissions of each non-directory, and, if it's not writable, prompt if stdin is a terminal)?
it'd be trivial to modify that behavior to refuse to continue in such a case if you want double seatbelts
also, if the changes were staged they were recorded in the database and remain there