4 ms·

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/3a694c2a077451e3d446

by chx 9y ago

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

jononor 9y ago
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
- chx 9y ago
  A revision control system losing data on a bad ctrl+r is, as I mentioned, a menace.
- weberc2 9y ago
  Having to navigate the reflog as a beginner can be overwhelming.
swift 9y ago
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". =)
- bsder 9y ago
  Except that "git commit" isn't sufficient. 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."

by chx 9y ago

jononor 9y ago

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

chx 9y ago
A revision control system losing data on a bad ctrl+r is, as I mentioned, a menace.
weberc2 9y ago
Having to navigate the reflog as a beginner can be overwhelming.

swift 9y ago

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

bsder 9y ago
Except that "git commit" isn't sufficient. 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."