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

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