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

> On Feb 18, 2015, at 01:46, Michael J Gruber wrote:
>> 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.
> 
> There was this concept of a git stash checkpoint to save work in  
> progress without creating a normal commit that I read about some time  
> ago (blog? Git book? -- don't recall) that was basically just this:
> 
>    git stash save
>    git stash apply
> 
> The problem with that is that it touches the working tree and can  
> trigger rebuilds etc.  However, when I ran across the undocumented  
> "git stash create" command I was able to write a simple git-checkpoint  
> script [1] that creates a new stash entry without touching the index  
> or working tree which I find quite handy from time to time.

> So I think that what Armin originally asked for (create a dangling  
> commit of changes before reset --hard) could be accomplished simply by  
> running:
> 
>    git checkpoint && git stash drop
> 
>> 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).
> 
> But of course plugging that into git reset somehow is indeed the  
> problem since you cannot alias/redefine git commands.
> 
> -Kyle
> 
> [1] https://gist.github.com/mackyle/83b1ba13e263356bdab0