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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]