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

[Michael J Gruber <git@drmicha.warpmail.net>]

Armin Ronacher venit, vidit, dixit 16.02.2015 14:29:
> Hi,
> 
> On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:
>> 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?
> This was only the second time in years of git usage that the reset was 
> incorrectly done.  I suppose at this point I might try to retrain my 
> muscle memory to type something else :)
> 
>> 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).
> I don't think that's necessary, I don't think it would make the 
> operation much slower to just make a dangling commit and write out a few 
> blobs.  The garbage collect will soon enough take care of that data 
> anyways.  But I guess that would need testing on large trees to see how 
> bad that goes.
> 
> I might look into the git undo thing that was mentioned.
> 
> 
> Regards,
> Armin
> 

Are you concerned about the index only, not unstaged worktree changes?

In this case, keeping a reflog for the index may help, and it would
somehow fit into the overall concept.

Otherwise, we would basically need a full stash before a hard reset.
That's not the first time where we could need a distinction between
"command run by user" and "command run by script". For the former, we
could allow overriding default options, re-aliasing internal commands,
adding expensive safety hooks. For the latter we can't.

It's just that we don't have such a concept yet (other than checking tty).

Michael