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

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

onsdag 01 november 2006 21:49 skrev Junio C Hamano:
> Andy Parkins <andyparkins@gmail.com> writes:
> > 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^?
>
> Path limiters everywhere in git means "do this only for paths
> that match this pattern, and empty path means the pattern match
> every path -- the command's behaviour is not different in any
> other aspect between the case you gave no limiter and the case
> you gave _all_ paths as limiters".  So the other paths remain as
> they were (both index and working tree), and HEAD needs to be
> updated to HEAD^ in the above example.
>
> While that perfect makes sense from mechanical point of view, I
> am not sure what it _means_ to keep some paths from now
> abandoned future while having some other paths reset to the
> rewound commit, from the point of view of end-user operation.
>
> In other words, I do not have a good explanation on what "git
> reset [--hard|--mixed] <commit> <path>..." does that I can write
> in the documentation.

You could refer to git-checkout although checkout doesn't have something 
corresponding to --mixed. The --hard option would correspond to the -f flag 
in checkout.

It is like "cherrypicking" content (not changes) from a particular commit.  

Where did the soft option go? 

Since checkout already does the work.. Is there any need for extending 
git-reset, other than that's where people look for this feature. The man page 
could be extended instead.