Re: Restore a single file in the index back to HEAD

[Junio C Hamano <junkio@cox.net>]

Andy Parkins <andyparkins@gmail.com> 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.