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

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

[Shawn Pearce]

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.

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

[Linus Torvalds]

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

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

[Shawn Pearce]

Alex Riesen <raa.lkml@gmail.com> wrote:
> On 5/17/06, Shawn Pearce <spearce@spearce.org> 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.