VCS Reset vs. Re‑run ng update After a Half‑Migrated Angular Upgrade

Goal

Recover an Angular workspace that was left in a half‑migrated state after a failed ng update run.

Constraint

The migration process rewrites source files and updates package.json and the lockfile incrementally. If the process stops midway, earlier migrations may have already altered code, while later ones remain pending. Re‑running ng update on this polluted tree risks double‑applying or skipping transformations, and peer‑dependency conflicts may persist.

Unresolved Decision

Should the upgrade be rolled back to a clean commit in version control and then re‑executed, or should the same upgrade be retried with --force or --allow-dirty after addressing the root cause?

Questions

• Is performing a git reset --hard to the last good commit and reinstalling dependencies the safest way to guarantee a clean baseline before re‑running ng update?
• Can re‑running ng update with --force after fixing peer‑dependency conflicts reliably apply the remaining migrations without double‑applying earlier changes?
• Which approach—full reset or forced retry—offers the most predictable migration state for a workspace left partially migrated?