JHipster upgrade: diagnosing partial application of changes after a failed run

Goal

Determine how to safely roll back or complete a JHipster upgrade that stopped mid‑execution, leaving the project in a state with conflict markers and unresolved dependencies.

Constraints

The upgrade sub‑generator does not create a backup or stash local modifications automatically. A failure can leave files such as pom.xml or package.json with merge conflict markers and may leave dependency versions partially updated, causing build failures.

Unresolved Questions

• What automated checks can detect that an upgrade was interrupted and that the repository contains partial changes?
• Which Git workflow (commit, stash, temporary branch) best preserves the developer’s work while allowing the upgrade to be retried or rolled back?
• Does JHipster provide, or could it provide, a flag or command to automatically revert to the pre‑upgrade state when a failure is detected?