Add confirmation for nuking the working tree

[DawidPietrykowski]

• PR Description

This is a small PR that extends the logic added in #4704

There were many reports of users accidentally resetting the working tree using the reset commands and a nice change was added by @stefanhaller to prompt for confirmation on those actions but the "Nuke working tree" option was not covered by the PR.

I believe this one is actually one of the most important options to prompt because it's by default the first one on the list. I myself triggered it once when trying to discard a single file while unknowingly having caps-lock enabled as I thought I was confirming the single file discard option.

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

Thanks for adding this, I agree it makes sense to warn here, too.

However, I don't think it's quite good enough, because the confirmation explicitly talks about untracked files, and we do indeed blow away untracked files, however the warning doesn't appear when there are only untracked files.

It would be possible to extend the condition by || helpers.AnyUntrackedFiles(self.c.Model().Files) (which doesn't exist, but we could add it). However, this would still not catch the case where users do git config --global status.showUntrackedFiles false.

In conclusion, I think it makes the most sense to show the warning always, unconditionally.

[DawidPietrykowski]

Understood, thanks for taking the time to look at this!

I didn't understand IsWorkingTreeDirtycorrectly then, as I thought it would also cover untracked fies. I also didn't know about the git setting to disable showing untracked. Then the best solution will be to always show this.

I'll remove the condition check, move the message and update the PR.

[stefanhaller]

I didn't understand IsWorkingTreeDirtycorrectly then, as I thought it would also cover untracked fies.

No it doesn't, and just in case you are wondering whether it should: no, it shouldn't 😄. For the existing call sites of the function, untracked files are not relevant (e.g. to decide whether changes need to be auto-stashed before doing some operation).

[DawidPietrykowski]

Implemented the changes

[stefanhaller]

Thanks!

[Monsterovich]

Accidentally pressed some sh*t. Boom! Changes gone with a cool effect (the history of changes in the IDE was helpful). Thank you for fixing this.