git-add + git-reset --hard = Arrrggh!

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.

On Wed, 17 May 2006, Shawn Pearce wrote:

It doesn't.

Just do "git fsck-objects". It should have said

	dangling blob <sha1>

and you can just do

	git cat-file blob <sha1> > 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

Alex Riesen <raa.lkml@gmail.com> wrote:

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. :-)