Hi, Jakub Narebski wrote: > Mike <xandrani@xxxxxxxxx> writes: >> % git reset --hard HEAD~1 > > Errr... here you screwed up. This reset state of you working area to > the state at last commit, removing all your changes to tracked files. Or rather, here we screwed up. Jakub and others gave some useful advice about how to recover, so let's consider how the UI or documentation could be improved to prevent it from happening again. * In this example if I understand correctly then the index contained some useful information, perhaps about a larger commit intended for later. To preserve that, you could have used git reset --soft HEAD~1 which would _just_ undo the effect of "git commit", leaving the index and worktree alone. * Another situation that comes up from time to time is making a change that just turned out to be a bad idea. After commiting it, you might want to discard the erroneous change, like so: git reset --keep HEAD~1 The "--keep" option uses some safeguards to make sure that only the committed change gets discarded, instead of clobbering local changes at the same time. * In the early days of git, the "--keep" option did not exist. So a lot of old documentation recommends to do git reset --hard HEAD~1 which is the same if you don't have any local changes. It would be useful to fix such documentation by adding a few words about local changes. Recently Duy wrote a patch to improve "reset -h" output in that vein, but discussion drifted off: http://thread.gmane.org/gmane.comp.version-control.git/170266 I also sent a couple of documentation patches and then dropped the ball: http://thread.gmane.org/gmane.comp.version-control.git/165358 http://thread.gmane.org/gmane.comp.version-control.git/160319 If someone wants to pick any of these up and run with it, I wouldn't mind (hey, I'd be happy). Thanks for a useful example. Jonathan -- To unsubscribe from this list: 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