Andy Parkins <andyparkins@xxxxxxxxx> writes: > As I mentioned in my original email, I was wishing for > > git-reset --mixed HEAD oops/file1 > > But of course, that doesn't make any sense in the context of of git-reset, > which is really only a HEAD manipulator with extras. Well, reset historically is _not_ HEAD manipulator. It is the primarily Porcelain-ish to recover the index and/or the working tree that is in an undesired state. So from that point of view, the above commandline perfectly makes sense. However, giving anything but HEAD with path makes us go "Huh?" It is unclear what this should mean: git-reset [--hard | --mixed] HEAD^ oops/file1 Checkout is a working tree manipulator Porcelain, and as a side effect it has always updated the index. So it might make sense to give --index-only there: git checkout --index-only HEAD -- paths... But from UI and workflow point of view, I think the situation under discussion is that the user wishes to _recover_ from an earlier update-index that he did not want to do. Although update-index is not designed as a UI but as a plumbing, it has been used as such (and git-status output even suggests use of it), so maybe it is not such a bad idea to bite the bullet and declare that it now _is_ a Porcelain-ish. Then we can do what you suggested (with missing <commit> defaulting to HEAD): git update-index --reset [<commit>] -- paths... I am not enthused by this avenue, though. I'd like to keep low level plumbing as "tool to do only one thing and one thing well" and update-index is as low level as you would get. On the other hand, we already have --again, so maybe we have already passed the point of no return. So I am inclined to agree with your "update-index --reset" approach, unless somebody else injects sanity into me. - 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