Re: Some advanced index playing

From: Linus Torvalds <torvalds@osdl.org>
Date: Dec 3, 2006, 18:34 UTC
Message-ID: <Pine.LNX.4.64.0612031024480.3476@woody.osdl.org>
In-Reply-To: <200612031701.15594.alan@chandlerfamily.org.uk>

On Sun, 3 Dec 2006, Alan Chandler wrote:

Show 7 quoted lines

> 
> c) Revert the entire index back to the state it was at the last commit so I 
> can selectively add back in the files that I have editted.
> 
> The command to do that seems to be
> 
> git-read-tree HEAD

A side note on this..

It definitely works, but it's not really the right thing to do for a few reasons:

 - it isn't even what you wanted. You didn't want to reset _all_ the index 
   values, you only really wanted to reset a few of them. So as mentioned 
   in the previous email, the command sequence you'd wanted for that 
   operation is

	git ls-tree <tree> -- <path pattern list> |
		git update-index --index-info

But, that said, if you actually want to reset the whole index, "git-read-tree HEAD" works, but is not what you should do:

 - you really want to keep the index "stat()" cache valid, and 
   git-read-tree will throw that all out. So you would need to do a

	git update-index --refresh

   after you've reset the index ("git status" will do it for you, and if 
   you don't do either "git status" or the above,

 - instead of re-reading the index 100% and then having to refresh it back 
   to mostly the same stat() into it already had, you can _merge_ the old 
   index with the information in HEAD, by using

	git read-tree -m HEAD

   which basically does a merge from the old index and the HEAD tree.

 - However, that actually fails if the old index wasn't just dirty, but 
   had unmerged paths etc, because then a "merge" would throw away that 
   unmerged information. So what you _really_ want to do is

	git read-tree --reset HEAD

   which (as the flag implies) will _reset_ the index to the tree in HEAD, 
   and this will do exactly what you were looking for: keep the "stat()" 
   information alone, but reset the actual index contents.

 - HOWEVER. This is exactly what "git reset" does.

So in short, you should just have done "git reset", and you'd have reset your index back to the state of your last commit.

So "git reset" is generally your friend whenever something goes wrong. If you also want to reset your checked-out files (which you did NOT want to do in this case, of course), you would have added the "--hard" flag to git reset.

And that (finally) concludes this particularly boring "git usage 101" session.