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

From: Andy Parkins <andyparkins@gmail.com>
Date: Nov 2, 2006, 08:44 UTC
Message-ID: <200611020844.12357.andyparkins@gmail.com>
In-Reply-To: <7vejsmzqh6.fsf@assigned-by-dhcp.cox.net>

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

Show 8 quoted lines

> 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