When running migrations, the origional starting migrations should be shown.

[Timothy Hobbs]

In order to make it easier to roll back migrations, it would be quite useful to show the migrations that were applied immiediately before the run migrations. For example:

Instead of displaying:

Operations to perform:

  Apply all migrations: admin, admin_tools_stats, advanced_filters, aklub, auth, celery_monitor, computedfields, contenttypes, dashboard, django_celery_beat, django_nyt, flexible_filter_conditions, helpdesk, import_export_celery, import_export_celery_edit, interactions, menu, oauth2_provider, post_office, repolinks, sessions, sites, smmapdfs, smmapdfs_edit, thumbnail, wiki, wiki_attachments, wiki_images, wiki_notifications

Running migrations:

  Applying admin.0002_auto_20190108_1629... OK

  Applying admin.0002_auto_20181114_1448... OK

  Applying admin.0003_merge_20190120_1444... OK

  Applying admin.0004_auto_20190826_2034... OK

  Applying admin.0005_auto_20190904_1547... OK

  Applying admin.0006_auto_20190909_0912... OK

There would be:

Operations to perform:

  Apply all migrations: admin, admin_tools_stats, advanced_filters, aklub, auth, celery_monitor, computedfields, contenttypes, dashboard, django_celery_beat, django_nyt, flexible_filter_conditions, helpdesk, import_export_celery, import_export_celery_edit, interactions, menu, oauth2_provider, post_office, repolinks, sessions, sites, smmapdfs, smmapdfs_edit, thumbnail, wiki, wiki_attachments, wiki_images, wiki_notifications

Starting from:

   admin.0001_auto_20180108_1629


Running migrations:

  Applying admin.0002_auto_20190108_1629... OK

  Applying admin.0002_auto_20181114_1448... OK

  Applying admin.0003_merge_20190120_1444... OK

  Applying admin.0004_auto_20190826_2034... OK

  Applying admin.0005_auto_20190904_1547... OK

  Applying admin.0006_auto_20190909_0912... OK

This way it would be easy to roll back the migration simply by copying the origional migration name

./manage.py migrate  admin.0001_auto_20180108_1629

[Carlton Gibson]

We already have showmigrations to see the applied (and unapplied) state. As such I'm inclined to wontfix here.

In any case, the applied migration state isn't a single migration, but the leaf migrations for each app. You've got (I think) 29 apps listed there, so you'd need 29 lines of output. Maybe we could reduce that analysing-out dependencies, but it doesn't seem worth the complexity: just use showmigrations.