# git-add + git-reset --hard = Arrrggh! 3 messages from 2006-05-17 to 2006-05-17. Participants: Shawn Pearce, Linus Torvalds. Thread: https://gitlist.dev/t/4175 ## Shawn Pearce, 2006-05-17 09:45 Subject: git-add + git-reset --hard = Arrrggh! Message-ID: <20060517094526.GA8563@spearce.org> URL: https://gitlist.dev/e/20060517094526.GA8563%40spearce.org ``` After spending an hour writing and testing a new test case for GIT I do the foolish: $ git add t/t1400-update-ref.sh # Hmm, maybe I should amend this into the prior commit. $ git format-patch -o .. next $ git reset --hard $ git update-ref HEAD~1 # Uhhohh... $ ls t/t1400-update-ref.sh All I can say is I'm very happy that update-index does a lot more than just update the index. I was easily able to find the deleted test by finding the most recently modified object in my .git/objects directory and pulling it back out with git cat-file. :-) Oh, and I totally agree with that discussion about GIT not clobbering files the user is working on which the user can't easily recover. I just wish recovery from the above stupidity didn't require going through .git/objects looking for the newest file. :-) Yes, I know that git reset --hard was brutal and yes, I didn't really need to use git-update-ref when git-reset would have also done the job for me. Arrgh. Its early and I wasn't thinking. -- Shawn. ``` ## Linus Torvalds, 2006-05-17 14:43 Subject: Re: git-add + git-reset --hard = Arrrggh! Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0605170735540.10823%40g5.osdl.org In-Reply-To: <20060517094526.GA8563@spearce.org> ``` On Wed, 17 May 2006, Shawn Pearce wrote: > > Oh, and I totally agree with that discussion about GIT not clobbering > files the user is working on which the user can't easily recover. > I just wish recovery from the above stupidity didn't require going > through .git/objects looking for the newest file. :-) It doesn't. Just do "git fsck-objects". It should have said dangling blob and you can just do git cat-file blob > missing-file-name and you're done. That said, I think we should make everybody very aware of just how a _dangerous_ operation "git reset --hard" is. It does delete your work. On purpose. The fact that you can sometimes get it back doesn't change anything. (And I say "sometimes", because you'll obviously have lost all the modifications that are only in your working tree - both to any added files and to any old-time files. That's the _point_ of it, after all). The default for "git reset" is to _not_ do any modifications in the working tree. And there's a reason that's a default ;) Linus ``` ## Shawn Pearce, 2006-05-17 21:35 Subject: Re: git-add + git-reset --hard = Arrrggh! Message-ID: <20060517213516.GA30313@spearce.org> URL: https://gitlist.dev/e/20060517213516.GA30313%40spearce.org In-Reply-To: <81b0412b0605170722u15702301p2565e8ac29a5a0da@mail.gmail.com> ``` Alex Riesen wrote: > On 5/17/06, Shawn Pearce wrote: > >All I can say is I'm very happy that update-index does a lot more > >than just update the index. I was easily able to find the deleted > >test by finding the most recently modified object in my .git/objects > >directory and pulling it back out with git cat-file. :-) > > > > Maybe git-lost-found would help here? Thanks! I did that the hard way with git fsck-objects only to find I actually had a lot of dangling objects. Luckily the most recent one was the one I was looking for so a quick pipe through perl and ls -t found it quite quickly. What would have really helped me was just using GIT properly rather than slamming something in fast with `git reset --hard`. Somehow that option has become part of my finger feel when using reset and that's just not right. :-) -- Shawn. ```