[amcoy37]

Accidentally running a git command in the wrong folder is pretty easy to do at the command line.

I was, at one point, in the habbit of running "git checkout ." after writing some experimental code. Several times a day, or however often. So of course, I once accidentally ran that command in the wrong repo and obliterated some pending changes that hadn't been commited.

[dotancohen]

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.

[Someone]

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.

[nemetroid]

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

[Someone]

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.

[nemetroid]

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.

[eropple]

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.

[sagarm]

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