On Sun, 3 Dec 2006, Alan Chandler wrote:
>
> 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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html