Re: Experience with Recovering From User Error (And suggestions for improvements)

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Feb 16, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Mon, Feb 16, 2015 at 11:41 AM, Armin Ronacher
> <armin.ronacher@active-4.com> 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).