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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html