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

Andy Parkins [off-list ref] writes:

On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:

quoted

quoted

quoted

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

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.

quoted

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.

On Wednesday 2006, November 01 22:08, Junio C Hamano wrote:

quoted

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

Sorry, yes, it's there merely to get in the way.

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.

Hmmm, no I had imagined that in path mode HEAD would not be updated because 
that would change the whole commit instead of just the particular file.

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

That's the one.  It was described in another response as cherry-picking 
content instead of commits.

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

Agreed.  --soft + path can't have any effect because it only updates HEAD, 
which has no meaning in reset-path mode.

Ok, that workflow certainly makes sense.

When this thread gets looked back upon, is it going to be strange that you 
say "yes, making crazy changes makes sense"?  :-)

That's the "mechanical point of view only" description I was
afraid of having.  While I think I now see why they can be

I must have a "mechanical point of view" brain.  I can't see any further than 
the gear wheels.



Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE