From: Junio C Hamano <junkio@cox.net>
Date: Wed, 11 Jan 2006 19:37:26 GMT
Subject: Re: reverting back both working copy and commits
Message-ID: <7vslrutv2h.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f@mail.gmail.com>

Bahadir Balban <bahadir.balban@gmail.com> writes:

> % git-branch master-2006-get-rid-of-commits
>
> % git-reset --hard [sha1id]
>
> where sha1id is the id of commit I want to revert back to. After this,
> git-log points at the right commit (the one with [sha1id]) as the last
> commit made. However, the working copy is left in the original state,
> i.e with the unwanted changes.

Eh?  That should not happen.

Could you elaborate?

	$ git diff master-2006-get-rid-of-commits

should show differences between the wrongly committed state and
your working tree.

	$ git diff --cached HEAD ;# or git diff --cached [sha1id]

should show *nothing* and

	$ git diff HEAD ;# or git diff [sha1id]

should also show nothing.

What is different between what I just described "Thess should
happen" and what actually happens to you?  I use "git reset
--hard" all the time, probably a lot more often than other
people, and I'd be surprised if things are not working.

What "git reset --hard" would leave behind are files in the
working tree that you had when you made the wrongly done commit,
which were *not* known to git (i.e. you forgot to "git add"
before committing).  Since they are not known to git, "reset --hard"
does not touch them.