On Mon, Feb 16, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > 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. "Recovery like this easier", i.e. make it easier to get back previously staged commits / blobs. > 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