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

[Andy Parkins <andyparkins@gmail.com>]

On Thursday 2006 October 26 16:42, Alex Riesen wrote:

Thanks for your suggestion.

> Use "git checkout HEAD oops/file1"

This returned:

"git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'oops/file1' which can not be resolved as commit?"

I'm not sure that checkout will do what I want anyway because it would 
overwrite the working directory copy of oops/file1.  I want to keep the 
changes but reset the index to have oops/file1 from HEAD.

Maybe I need to say a little more about what I'm trying to do:

I converted a subversion repository to git.  In that repository I maintained 
my own set of patches in one branch against an upstream branch; I'm now using 
git-cherry-pick to pull a subset of those patches onto a new branch against 
the upstream head.  This is all working fine.  The problem is that I've come 
across a patch that should rightly be two patches instead of one.  

So, I cherry-pick a patch, which updates the working directory and index, 
leaving me with...

# On branch refs/heads/newmaster
# Updated but not checked in:
#   (will commit)
#
#   modified:   oops/file1 
#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4

Instead, what I would like is

# On branch refs/heads/newmaster
# Updated but not checked in:
#   (will commit)
#
#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4
#
# On branch refs/heads/newmaster
# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#   modified:   oops/file1 

I've actually found a way around the problem.  I do git-reset HEAD, which 
restores the index entirely but leaves the working directory.  Then I 
git-update-index the good/* set.  However, it led me to wonder what the 
inverse of git-update-index is.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE