Re: reverting back both working copy and commits

From: Junio C Hamano <junkio@cox.net>
Date: Jan 11, 2006, 19:37 UTC
Message-ID: <7vslrutv2h.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f@mail.gmail.com>

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

Show 8 quoted lines

> % 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.