Thread (2 messages) flat view 2 messages, 2 authors, 2016-08-11

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

From: Andy Parkins <hidden>
Date: 2016-08-11 19:55:23

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help