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

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

Andy Parkins <andyparkins@gmail.com> writes:

Show 14 quoted lines

> On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:
>
>> >> 	git-reset [--hard | --mixed] HEAD^ oops/file1
>> 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.
>
> Isn't that exactly what the user would be asking for when they are doing a 
> per-file reset?  This is a contrived example as git makes it easier to do it 
> in far more sensible ways; but I've done this before now in subversion...  
> What if I want to try out some radical change?  It goes like this:
>
> x --- y --- z

I assume when you do the following operation your .git/HEAD points at 'y' which is already committed, and 'z' does not exist yet (it does not come into the scenario you describe below).

Show 8 quoted lines

> Where x is some stable commit; y is a load of crazy changes;
> we discover that the crazy changes are all fine except for
> one, and so want to rollback one file, without yet commiting:
>
>  git-reset --hard HEAD^ frotz
>
> Git would get frotz from HEAD^ and write it to the working directory and the 
> index (or just index with --mixed).

You forgot to mention at the same time it makes .git/HEAD point at 'x'. That's the part I am not so sure about.

Ah (lightbulb goes on). So after the above reset, you would do a "git commit" with or without -a to create a fixed-up 'y' that does not have changes to 'frotz'?

Then it sort of makes sense. --soft with paths specifier does not make much sense (paths specifier is a no-op in that case because --soft does not touch index nor working tree), but I wonder what workflow --mixed would help. It resets the index for frotz from 'x', while your crazy changes of 'y' is still in the working tree. You can "git commit" without -a to create the same fixed-up 'y' that does not have changes to 'frotz', and then keep working on 'y' to make it into less crazy.

Ok, that workflow certainly makes sense.

Show 16 quoted lines

>> 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.
>
>  --mixed
>    Resets the index but not the working tree (i.e., the changed files are
>    preserved but not marked for commit) and reports what has not been
>    updated. This is the default action.  If <path> is given then only that
>    path will be reset to the state that <path> had in <commit-ish>.  The
>    working tree will be untouched.
>
>  --hard
>    Matches the working tree and index to that of the tree being switched to.
>    Any changes to tracked files in the working tree since <commit-ish> are
>    lost.  If <path> is given then only that path will be reset in both the
>    working tree and the index to the state that <path> had in <commit-ish>.

That's the "mechanical point of view only" description I was afraid of having. While I think I now see why they can be useful, we would need to extend the examples section to demonstrate how they help workflows to readers.