Guess I meant that one -- I had sometimes problems with wrong commits
that I didn't get reset somehow. As I understand, if I do a commit and
revert it, there is another commit doing the
On Thu, 4 Sep 2008, till Rettig wrote:
- -) "git checkout filename" -- discards all non-committed changes to the
I thought that works only if you remove the file before?
No, it works also with dirty files, i.e. files that have been modified,
but not committed.
The only exception is if you called "git add <filename>". The reason is
the so-called index.
I prefer to call it the "staging area". You can stage changes for commit,
and the way to do it is "git add". It is a very powerful concept, as it
allows you to add some change already, while working on the rest of the
commit, and "git diff" will show only the latter changes.
So the foolproof way to restore a file to the last committed version is
"git checkout HEAD -- <filename>".
Well, this could also be done with git rebase --hard...
You mean "git reset --hard"? That resets _all_ files. _And_ the staging