manage.py migrate --check --prune actually prunes, which is surprising

[Ari Pollak]

I ran "manage.py migrate --check --prune app" in a Django 5.1.4 app. Based on the description of --check, I expected this to not delete any migrations from the database, but just tell me which ones would be deleted, like a dry run. But it did delete outdated migrations from the django_migrations table.

To avoid surprising destructive behavior in the future, I think "migrate --check --prune" should either not be allowed to run with those combined options, or should just report which migrations would be pruned and not actually prune them.

[Natalia Bidart]

Hello Ari Pollak, thank you for this ticket. I can see the source of confusion, but I’d like to clarify that --check is not a dry-run`-like option. As described in the help output:

$ python -Wall manage.py migrate --help

Updates database schema. Manages both apps with migrations and those without.

[...]
options:
  --check               Exits with a non-zero status if unapplied migrations exist and does not actually apply
                        migrations.
  --prune               Delete nonexistent migrations from the django_migrations table.

The --check and --prune options operate independently and are unrelated. --check deals with migrations that exist on disk but have not been applied to the database, while --prune does the opposite, removes migration records from the database that no longer have corresponding migration files.

Given this, I don’t see a strong reason to prevent these options from being used together. If the concern is about unintended deletion, perhaps what this ticket is really suggesting is a --dry-run mode for --prune?