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

[Andy Parkins <andyparkins@gmail.com>]

On Wednesday 2006 November 01 23:39, Junio C Hamano wrote:

> That is not something other git commands with pathspec does.
> Path limiters tell command to "do your thing only for paths that
> match these patterns, while you usually handle all paths; your
> behaviour shall otherwise not be any different in other aspects
> between the case you got no limiter and the case you got _all_
> paths as limiters."  So I do not think making path-only mode and
> pathless mode behave differently is a good idea from the UI
> point of view.

Surely if you move HEAD you have implicitly affected every path?  In which 
case what effect did the path limiter have?

Given

 x --- y --- (z--Z)

With z being the index and Z being the working directory - both uncommitted.  
The file foo will be different in x, y, z, and Z.  We decide that z-foo is 
incorrect and that it was right in x; however, there are changes in Z-foo 
that we want to keep.

 git-reset --mixed HEAD^ foo

This would reset z-foo (because --mixed) to its state in HEAD^; i.e. x-foo.  
If HEAD changes as well then all the rest of y will be lost - not just y-foo.  
Remember the original problem was a way of selectively manipulating the index 
without altering the working directory.

I'm perfectly happy if git-reset is not the place to do this, because 
git-reset is only allowed to fiddle with HEAD/index; I moved to git-reset 
only because you mentioned that "reset historically is _not_ HEAD 
manipulator".

I think we're back to square one: there is no appropriate command to take on 
this functionality:

 git-ls-tree HEAD^ foo | git-update-index --index-info

 * git-reset can't have it because it makes no sense to alter HEAD /and/
   revert a file.  It also occurs to me that "git-reset --hard HEAD^ foo"
   (using my suggested git-reset implementation) would be redundant anyway
   because it's the same as "git-checkout -f HEAD^ foo".
 * git-checkout can't have it because it doesn't target the index.
 * git-update-index can't have it because it is plumbing and doesn't know
   about commits, only about objects.

I'm stumped now.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE