It's way too easy to lose work with git. The easy availability of git reset --hard is a menace. I am using this https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 shell script to make it not lose data. And it's a disgrace I need to do this. Disk space is free (within measurement error, especially for 99.99% of codebases) so just put that thing somewhere and if necessary I can use date and pickaxe to dig it up.
I do agree with that; "git reset --hard" should stash the changes in the working copy somewhere. I'm sure you'd agree, though, that backing up your repository is not going to protect you from "git reset --hard" unless what you're really doing is backing up the working copy, and if that's what you're doing, there's a built in feature to do that in git called "git commit". =)
You have to use "git add" on a bunch of files that you have used "git add" on before.
As far as I can tell, every other revision control system tracks a file for "commit" once it has had even a single "add". This is the default case and what 99% of people want--"I told you to keep track of the file. Now keep track of it until I tell you otherwise."
git is the only revision control system I know of where I have to "git add" the same file over and over and over and over ... before doing "git commit".
But that is fairly standard git UI practice--"Optimize the 1% case and make the 99% case annoying."
git reflog has the previous refs, git reset --hard does not remove anything that has been committed.
It will however nuke changes that are not committed. Which is exactly what I use it for... But your script sounds like a decent solution if you want also that to be undoable
