git sync --pull leaves repo at a "rewritten" commit if the last checkout fails

[ppwwyyxx]

Description of the bug

git sync --pull will rebase my current stack onto the new main, and checkout to the corresponding commit on the new stack.

However, if my current repo has uncommitted changes, the step "checkout" may fail.

Despite that git sync --pull fails in the last step, the stack is still rebased, and the old commits were rewritten to the new stack.

At this moment, the correct user action, is for them to address the checkout failure (e.g. with a stash), and manually checkout to the new stack. Otherwise they are left at a rewritten commit in the old stack. I think this could be confusing. For instance, today one user thought "sync failed, so I'll remove my uncommitted changes and sync again", and they ended up with two identical stacks.

Expected behavior

I wonder what could make the experience more straightforward in the above scenario, e.g.:

1. Maybe sync --pull can revert to the initial state, if the last checkout failed.
2. Maybe sync --pull can refuse to run, if it founds the current commit needs to be rewritten AND the current repo has uncommitted changes.

Actual behavior

No response

Version of rustc

No response

Automated bug report

No response

Version of git-branchless

git-branchless-opts 0.8.0

Version of git

git version 2.25.1