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

The short answer

A failed jhipster upgrade almost always leaves your repository in a conflicted Git merge state, not in some unrecoverable limbo. If the merge is still in progress, git merge --abort returns you to the exact pre-upgrade state. There is no JHipster flag that auto-reverts on failure — rollback is a Git operation, and the safest way to retry is on a dedicated branch with a clean working tree.

What actually happened (likely explanation vs. confirmed)

Confirmed behavior: since JHipster 4, the upgrade sub-generator works by generating a fresh reference project on a temporary branch and merging it into your current branch. When it stops mid-run, the merge is left unresolved, which is why pom.xml or package.json contain <<<<<<< markers and dependencies look half-updated.

Likely, but verify in your repo: the generator's temporary branch (named like jhipster_upgrade_*) may still exist, and no merge commit was created. Confirm with git status (look for "both modified" entries) and git log --oneline -3 (the tip should be your pre-upgrade commit, not a merge commit).

Detecting the partial state

• git status — unmerged paths mean a merge is still open.
• git diff --name-only --diff-filter=U — lists exactly which files carry conflict markers.
• ./mvnw validate and npm install — both fail fast on malformed XML/JSON, confirming the tree is not buildable.

There is no dedicated JHipster "doctor" command; Git is the source of truth here.

Rollback steps for this case

1. Confirm no merge commit exists: git log --oneline -3. If the tip is a merge commit, stop and use git reset --hard HEAD~1 instead of step 2.
2. Abort the in-progress merge: git merge --abort.
3. Delete any leftover generator branch: git branch -D jhipster_upgrade_* (list first with git branch).
4. Verify: git status shows a clean tree, git diff HEAD -- pom.xml package.json package-lock.json is empty, and ./mvnw validate plus npm ci pass.

Retrying without risking your work

Commit or stash everything first — running the upgrade on a dirty tree is what makes rollback ambiguous. Then isolate the attempt:

git checkout -b upgrade-attempt
jhipster upgrade
# on success: merge back; on failure: git merge --abort && git checkout main

On JHipster 8+, jhipster upgrade --dry-run previews changes without writing files — useful for gauging conflict risk, though it doesn't guarantee a clean merge. Also confirm node --version and java -version match the target JHipster version's requirements before retrying; version mismatches can cause silent partial updates.

On the auto-revert question

As of current JHipster releases there is no --revert-on-failure option; the generator delegates to Git and cannot roll back atomically once merging starts. If you repeatedly hand-edit generated files, consider keeping those customizations as a patch file or blueprint so each upgrade applies them cleanly instead of conflicting every time.

One detail that would change this advice: whether a merge commit was already created before the failure — that determines merge --abort versus reset --hard HEAD~1.