David Kastrup <dak@xxxxxxx> writes: > That there is _another_ way to achieve a similar effect should not be > a deterrent to let git-reset do the _obvious_ thing for all partial > resets. At least please leave --soft out of it. The option is specifically defined as "Not touching index nor work tree", so "git reset --soft <arbitrary-commit> paths..." is by definition a no-op. One opposite approach that has already discussed on the list when Carlos posted his rewrite of "git reset", and I tend to agree to, is to fix git-reset so that it does not internally default to --mixed. It will have _four_ distinct cases, instead of the current three and half: - git reset <commit> -- paths: reset the index entries for given paths from the named commit; - git reset --hard <commit>: move the HEAD and reset the whole index and the work tree; - git reset --mixed <commit>, git reset <commit>: move the HEAD and reset the whole index; - git reset --soft <commit>: move the HEAD and leave index and work tree alone. Only because it internally defaults to --mixed mode by setting the reset-type too early in the code, the current implementation happens to allow "git reset --mixed <commit> -- paths", which is a nonsense. "paths" form is totally different from the usual reset whose primary purpose is to move HEAD, and allowing this form makes the command look unorthogonal. If we do the above change that inconsistency will go away. - 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
