that's like saying that 'rm -rf' is destructive 'without warning.' Well, "rm -r" when run as root does warn. You have specified a flag that explicitly doesn't

that's like saying that 'rm -rf' is destructive 'without warning.' Well, "rm -r" when run as root does warn. You have specified a flag that explicitly doesn't not ask. Also, "rm" only ever destroys things, whereas "git checkout": - creates a new branch (non-destructive, additive) - switches to an existing branch (non-destructive) - obliterates uncommitted changes to a file (destructive) And the two major modes (destructive and non-destructive) have no syntactical differences. "git checkout X/Y" is non-destructive if X is the name of a remote and Y a file, and destructive if X is the name of a folder and Y a file. Deep down, you know this just isn't right. The chief problem with git is that the user interface is a simple reflection of the mechanics and vocabulary used to implement it. That first part is great for performance, and the whole thing might seem like a good idea if you happen to be a filesystem hacker, it's arbitrary nonsense to the rest of the world. git has been purposely architected so that you do not lose data. "stash" allows you to temporarily store local changes while you test things out. Extensive branching is key to sharing patches in a trackable way. Most destructive commands actually alert you that data will be lost. I really like this philosophy of never accidentally losing anything. But the interface is inconsistent and needlessly complex, and should not be defended. git could be vastly improved simply by changing the command structure and vocabulary. Destructive commands could universally prompt unless an option ("-f"?) is specified. Maybe someone could make "tig", which is a proper version control system organized from an everyday user's perspective, based on git.