Avoid accidental hard resets

[Reun85]

Is your feature request related to a problem? Please describe.
While managing my git repo, I accidentally dropped a pen I was fidgeting with on the keyboard, completely nuking all of my uncommitted changes (rip 6hrs). It took me a good while to even figure out what command may have been run. Only to realise that the keybind combination to perform a hard reset is gh, two buttons next to each other on the keyboard. I am now deeply scared and honestly baffled at how I have not fat-fingered these keys by accident previously.

Describe the solution you'd like
Make keybinds in the reset menu (and any other menu) changeable via the keybind config.

Describe alternatives you've considered
A confirmation menu for specifically unrecoverable destructive changes. (If implemented, the user must be able to opt-out.)

Additional context
I am not the first to propose this alternative. Previous requests were denied for the same reason the git cli tool denies them. Unlike a cli tool, in a tui application, accidents are going to happen, and the same argument here is unjustifiable in my opinion.

[stefanhaller]

Duplicate of #3085 and #3709.

Previous requests were denied

Can you link to any such previous requests that were denied?

I'm all for adding a confirmation for hard reset, but probably only when there are modifications in the working copy.

If implemented, the user must be able to opt-out.

I usually have a strong opinion about being able to opt out of annoying confirmations, but in this case it's such a destructive change that I'm fine with leaving it on unconditionally (but, as I said, only for hard reset and only when there are uncommitted changes).

[stefanhaller]

@Reun85 PR is here: #4705

Making the keybindings of the menu items configurable is also a good idea, but it's a bit of a bigger change because I don't want to pollute the user config with lots of individual menu item bindings. Some restructuring of the config would be necessary first. I'm still undecided whether I want to tackle this; I hope the confirmation prompt is good enough for now.

[ysl2]

+1, I think the keybinding gh to reset hard is a dangerous behavior because these two keys are too closely and very easy to trigger. gH even better but the final solution might be to provide a custom keybinding solution for user specific.