# reverting back both working copy and commits 4 messages from 2006-01-11 to 2006-01-12. Participants: Bahadir Balban, Andreas Ericsson, Junio C Hamano. Thread: https://gitlist.dev/t/3038 ## Bahadir Balban, 2006-01-11 16:32 Subject: reverting back both working copy and commits Message-ID: <7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f@mail.gmail.com> URL: https://gitlist.dev/e/7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f%40mail.gmail.com ``` 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 ``` ## Andreas Ericsson, 2006-01-11 19:28 Subject: Re: reverting back both working copy and commits Message-ID: <43C55C51.90305@op5.se> URL: https://gitlist.dev/e/43C55C51.90305%40op5.se In-Reply-To: <7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f@mail.gmail.com> ``` 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 git tag anchor git reset --hard 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 ``` ## Junio C Hamano, 2006-01-11 19:37 Subject: Re: reverting back both working copy and commits Message-ID: <7vslrutv2h.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vslrutv2h.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f@mail.gmail.com> ``` Bahadir Balban 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. ``` ## Bahadir Balban, 2006-01-12 10:40 Subject: Re: reverting back both working copy and commits Message-ID: <7ac1e90c0601120240u3f8d7571g5e5bf52b6d3c4c2a@mail.gmail.com> URL: https://gitlist.dev/e/7ac1e90c0601120240u3f8d7571g5e5bf52b6d3c4c2a%40mail.gmail.com In-Reply-To: <7vslrutv2h.fsf@assigned-by-dhcp.cox.net> ``` On 1/11/06, Junio C Hamano 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 ```