> If you take a look at the man pages for all of those commands you'll see they explicitly mention that your working tree will be affected.
I'm not complaining that these commands mismatch the spec. I'm complaining that the spec for these commands is badly designed.
> They are written explicitly to do that
I agree about git clean, but git reset --hard and git checkout do more than just changing the working tree.
> If you're ever unsure about the result of a given command make a copy of your current working tree before applying it. I like git because it explicitly doesn't hold your hand through things like this. It expects you to know what you're about to do.
You misunderstood my problem. I know exactly what these commands do.
I consider "reverting my changes in the working tree" to be a separate and irreversible thing of whatever "git reset" and "git checkout" do, and want git to ask for approval before accidentally doing irreversible damage.
The main thing protecting me from accidental errors/deletions/etc is my revision control system. But in this case, the irreversible damage is done BY the revision control system.
Here are a few examples of what I mean:
* I jump to the wrong shell. In it, I have an old "git status" that says my working tree is clean, but at the wrong location. I forget that I already moved it, and started working on a feature. I use "git reset --hard <correct-place>" and without warning, I also get my working tree changes irreversibly lost without any question.
* I press <up> a few times in my shell, to reach a previous command, hit <return>. OOPS, that command was not the one I intended. Instead it was a "git reset --hard <someplace>" or perhaps a "git checkout"!
* I may execute a command like "git checkout <refspec> <some_path>" during a merge in order to pick some version of that file. If I accidentally press <return> too early, I may lose all of my working tree changes in the directory.
I don't actually lose my working tree changes with git, because I'm aware of these issues, so I am very careful about which commands I replay.
But it would be nice to know that since I have a revision control backup of my files, I don't need to be as careful, as long as I don't use "clean", "rm" and other commands meant to lose information.
P.S: It would be nice if "checkout" stored a stash or such of any overwritten content so it isn't irreversible unless given a flag not to.
tl;dr: Good UI design dictates that user operations should be reversible whenever possible. Irreversible operations should require explicit confirmation (or at least "--force") and ideally should have no other effect except the specific irreversibility.
While all of what you say rings true - it's been said before and bears repeating - git isn't a version control system as much as it is a set of version control tools from which you can design a workflow that meets your needs.
The canonical way to use git is by the git syntax. Many (most?) people don't build scripts and aliases around it. It works just fine when used raw.
However, I'm with Peaker in that losing your working copy is enough of a nuisance to deserve an interactive prompt, just like 'rm' prompts by default. Confident users could always disable the prompt with an environment-variable or .gitconfig flag.
I'm not complaining that these commands mismatch the spec. I'm complaining that the spec for these commands is badly designed.
> They are written explicitly to do that
I agree about git clean, but git reset --hard and git checkout do more than just changing the working tree.
> If you're ever unsure about the result of a given command make a copy of your current working tree before applying it. I like git because it explicitly doesn't hold your hand through things like this. It expects you to know what you're about to do.
You misunderstood my problem. I know exactly what these commands do.
I consider "reverting my changes in the working tree" to be a separate and irreversible thing of whatever "git reset" and "git checkout" do, and want git to ask for approval before accidentally doing irreversible damage.
The main thing protecting me from accidental errors/deletions/etc is my revision control system. But in this case, the irreversible damage is done BY the revision control system.
Here are a few examples of what I mean:
* I jump to the wrong shell. In it, I have an old "git status" that says my working tree is clean, but at the wrong location. I forget that I already moved it, and started working on a feature. I use "git reset --hard <correct-place>" and without warning, I also get my working tree changes irreversibly lost without any question.
* I press <up> a few times in my shell, to reach a previous command, hit <return>. OOPS, that command was not the one I intended. Instead it was a "git reset --hard <someplace>" or perhaps a "git checkout"!
* I may execute a command like "git checkout <refspec> <some_path>" during a merge in order to pick some version of that file. If I accidentally press <return> too early, I may lose all of my working tree changes in the directory.
I don't actually lose my working tree changes with git, because I'm aware of these issues, so I am very careful about which commands I replay.
But it would be nice to know that since I have a revision control backup of my files, I don't need to be as careful, as long as I don't use "clean", "rm" and other commands meant to lose information.
P.S: It would be nice if "checkout" stored a stash or such of any overwritten content so it isn't irreversible unless given a flag not to.
tl;dr: Good UI design dictates that user operations should be reversible whenever possible. Irreversible operations should require explicit confirmation (or at least "--force") and ideally should have no other effect except the specific irreversibility.