[jsmeaton]

1. I think I'd like to see something like `./manage.py migrate --fresh`, which would forget about existing migrations, create a set in memory, and apply them. Pretty much emulating syncdb on a fresh database. Then the test runner could use that behaviour optionally (otherwise, RunPython statements may be missed that are required).

2. It may create more than 1 migration file if there are specific ordered dependencies afaik.

[ProblemFactory]

Does migration squashing do what you are looking for: https://docs.djangoproject.com/en/dev/topics/migrations/#squ... ?

After squashing and migrating all existing databases, you can delete the old migrations files. The squashed migration becomes the new fresh migration that should usually contain just "CREATE TABLE" statements to be run on an empty database.

[VuongN]

Using its best guess with dependency, it creates the appropriate migration file(s) favoring more files over potential conflicts. I think that's fine. The problem is consistency. However you choose to run the makemigrations, it should at least result in the same amount of files. It can't be more or less conflict if nothing is changed.