reverting back both working copy and commits

reverting back both working copy and commits

[Bahadir Balban]

Hi,

I made some commits that later on I wanted to cancel. I did:

% 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.. How do I also revert the working
sources into an earlier state.

Because git-commit says "nothing to change" at this stage, git
checkout -f does not cure my problem. How do I also revert working
copy to earlier commit?

Thanks,
Bahadir

Re: reverting back both working copy and commits

[Andreas Ericsson]

Bahadir Balban wrote:
> Hi,
> 
> I made some commits that later on I wanted to cancel. I did:
> 
> % 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.. How do I also revert the working
> sources into an earlier state.
> 

The branch where you do the reset is the one being reset, so you should 
have simply done the reset in the original branch without creating a new 
one. If you're nervous you're gonna screw up you can do this;

git checkout <branch-with-unwanted-commit>
git tag anchor
git reset --hard <commit-ish>

If you find you've landed on the wrong commit you can undo the change with

git reset --hard anchor

which will restore the branch to wherever you were prior to the first 
reset. Making an anchor tag is useful if you do several resets. You can 
use ORIG_HEAD to undo a single reset.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: reverting back both working copy and commits

[Junio C Hamano]

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.

Re: reverting back both working copy and commits

[Bahadir Balban]

On 1/11/06, Junio C Hamano <junkio@cox.net> wrote:
> Eh?  That should not happen.
>
> Could you elaborate?
> 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.

Sorry, it's my mistake, I later realised the working tree had been
updated correctly.

Thanks,
Bahadir