Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. > ... Here is another alternative. In hindsight, it would have been much better if we did not do "git reset <commit> paths..." from the beginning, and instead gave "git checkout" the "--cached" option, like other commands that have two modes of operation where they affect the index alone vs the index and the work tree. In such a case, canonically we say "--index" to mean the "affects both" version and "--cached" to mean the one that affects only the index. So "git reset <commit> paths..." should have been "git checkout --cached <commit> paths...". We still can do this, and then as a backward compatibility measure redo "git reset <commit> paths..." in terms of the latter. That would reduce the confusion and make things more orthogonal. - 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
