Windows "could not rmdir" leaves corrupt workspace state

[BC-MOR]

Version

0.18.3

Operating System

Windows

Distribution Method

winget (Windows)

Describe the issue

As described in #3560 when unapplying a stack which contains any directories which are open in e.g. VS Code gitbutler encounters the following error

command: unapply_stack
params: {"projectId":"17c57266-f021-47b3-89af-1dd3b8206376","stackId":"c63a3115-c88f-4e34-9238-7b7e31a5aa7d"})

could not rmdir 'G:/projects/<myProject>/': The process cannot access the file because it is being used by another process.
; class=Os (2)

This is a general problem but not the reason for the issue. GitButler also partially unapplies the stack and leaves the user in a broken state

To fix this the user has to go to the oplog and revert the last operation.

How to reproduce (Optional)

No response

Expected behavior (Optional)

I would propose that whenever GitButler encounters an error it reverts the last operation automatically so that there is no broken state. Alternatively a 'revert last operation' button in the error pop-up would also make this easier.

Relevant log output (Optional)

[Byron]

Thanks a lot for sharing!

We actually have a new implementation of "unapply" which should either succeed or fail without leaving traces of failure. Admittedly, when the checkout fails, it will still leave the worktree in that partial state, but nothing else should have changed so the changes can be discarded.

You can turn it on with "New apply to workspace".

[DesselBane]

(Same guy as BC-MOR just now writing from the correct github account 😅).

I already had this turned on.

[Byron]

Haha, thanks!

And after double-checking I realised that this is entirely wrong, as "unapply" isn't actually available as re-implementation.
It turns out that the new implementations, like "apply branch" already operate like this. At least now it does.

This means this issue would be closed once #10872 is done.