Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How is that git's fault?

I used to `vim test.c` then `rm Alt-.` very very often. Until one day sure enough I'm in the wrong directory, and I actually saw `Alt-.` complete the filename of an important file, but the brain veto latency is slower than the muscle memory twitch and my pinky continued on over to the Enter key.

I blame only Dotan and changed my work habits. Bash had nothing to do with the incident.



I don’t see anybody here claiming that’s git’s fault.

But it is an argument supporting the claim being discussed: that the statement “It is very hard to permanently lose work” is not quite true.


Using the command specifically designed to permanently discard work seems ”very hard” to me.


But it’s inconsistent in that. git checkout existing_branch complains with “error: Your local changes to the following files would be overwritten by checkout”* and abort, git checkout existing_directory overwrites files.

That’s what makes it easy to make that mistake, and lose data. It’s safe to use until it suddenly isn’t.


I just don't understand why someone would do git checkout existing_directory if they don't want to overwrite files, since that is all the command does.


I dunno - I can tell zsh to are-you-sure me about an `rm -rf *`, git seems like it should be able to do similarly. Or, as Mercurial does, back up overwritten files to .bak.

These are pretty light asks.


The sole purpose of git checkout -- file is to overwrite the file you explicitly listed. There should not be a confirmation by default.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: