On Mon, Feb 16, 2015 at 11:41 AM, Armin Ronacher <armin.ronacher@xxxxxxxxxxxx> wrote: > Long story short: I failed big time yesterday with accidentally executing > git reset hard in the wrong terminal window but managed to recover my > changes from the staging area by manually examining blobs touched recently. > > After that however I figured I might want to add a precaution for myself > that would have helped there. git fsck is quite nice, but unfortunately it > does not help if you do not have a commit. So I figured it might be nice to > create a dangling backup commit before a reset which would have helped me. > Unfortunately there is currently no good way to hook into git reset. > > Things I noticed in the process: > > * for recovering blobs, going through the objects itself was more > useful because they were all recent changes and as such I could > order by timestamp. git fsck will not provide any timestamps > (which generally makes sense, but made it quite useless for me) > * Recovering from blobs is painful, it would be nice if git reset > --hard made a dangling dummy commit before :) > * There is no pre-commit hook which could be used to implement the > previous suggestion. > > Would it make sense to introduce a `pre-commit` hook for this sort of thing > or even create a dummy commit by default? I did a quick googling around and > it looks like I was not the first person who made this mistake. Github's > windows client even creates dangling backup commits in what appears to be > fixed time intervals. > > I understand that ultimately this was a user error on my part, but it seems > like a small change that could save a lot of frustration. Something like "can we have a hook for every change in the working tree" has come up in the past, but has been defeated by performance concerns. "git reset --hard" is a low-level-ish operation, and it's really useful to be able to quickly reset the working tree to some state no matter what, and without creating extra commits or whatever. We should definitely make recovery like this harder, but is there a reason for why you don't use "git reset --keep" instead of --hard? It'll keep any local changes to your index/staging area, and reset the files that don't conflict, if there's any conflicts the operation will be aborted. If we created such hooks for "git reset --hard" we'd just need to expose some other thing as that low-level operation (and break scripts that already rely on it doing the minimal "yes I want to change the tree no matter what" thing), and then we'd just be back to square one in a few years when users started using "git reset --really-hard" (or whatever the flag would be). -- 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