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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 1, 2006, 20:49 UTC
Message-ID: <7vbqnq51v4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200611012029.41869.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> writes:

Show 10 quoted lines

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

Now I admit I am not the brightest in the git circle, but if I have trouble understanding what it does, can we expect other people to grok it?

Show 8 quoted lines

>> On the other hand, we already have --again, so maybe we have
>> already passed the point of no return.  So I am inclined to
>> agree with your "update-index --reset" approach, unless somebody
>> else injects sanity into me.
>
> Actually; you've talked me out of it.   Given that git-reset is already 
> porcelain, and none of the solutions are screaming "right"; it seems better 
> to slightly bend git-reset than git-update-index.

Well, now I am not sure of anything anymore ;-).