Philippe Vaucher <philippe.vaucher@xxxxxxxxx> writes: > A lot of time when I want to use reset for smth else than "--hard" I > have to go and look the documentation. I have to agree with this, I took a lot of time to understand/memorize the meaning of reset options. > Optional: a new mode would be introduced for consistency: > --worktree (or maybe --tree): only updates the worktree but not the index That would be an alias for "git checkout <rev> -- path", right? I don't really like this "there is more than one way to do it" in Git's command-line, I think we should think very carefully before introducing yet another instance of it. > --keep could be removed in favor of an additional --safe flag If you are to change the option names, then you should also make the behavior safe by default: * "git reset --all" = "git reset --keep" * "git reset --all --force" = "git reset --hard" With the current terminology, --hard has the advantage that it makes it realatively clear how dangerous it is. Still, I've seen users losing data because they did a "git reset --hard" with uncommited changes. Git is safe by default most of the time, and "git reset --hard" is one unfortunate exception (because it was there before --keep, people are more used to it). "git reset --all" would make it worse, because the option name is less scary, people would be less reluctant to use it, and would get more chance to lose data. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html