On Wednesday 2006, November 01 18:28, Junio C Hamano wrote: > 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 I don't understand. Why wouldn't that mean reset oops/file1 to the state it had in HEAD^? > 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... I think you're right that this is not the place - git-checkout is what one uses to update your working directory, it's only a side-effect that the index is updated - or we could argue that it is necessary that the index is updated in order that checkout can do it's job. > 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. Actually; you've talked me out of it. Given that git-reset is already porcelain, and none of the solutions are screaming "right"; it seems better to slightly bend git-reset than git-update-index. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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