What's the recommended approach to resetting migration history using Django South?

If you need to selectively (for just one app) reset migrations that are taking too long, this worked for me.

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

Don't forget to manually restore any dependencies on other apps by adding lines like depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial")) to your <app-dir>/migrations/0001_initial.py file, as the first attribute in your migration class just below class Migration(SchemaMigration):.

You can then ./manage.py migrate <app-name> --fake --delete-ghost-migrations on other environments, per this SO answer. Of course if you fake the delete or fake the migrate zero you'll need to manually delete any left-over db tables with a migration like this.

A more nuclear option is to ./manage.py migrate --fake --delete-ghost-migrations on the live deployment server followed by a [my]sqldump. Then pipe that dump into [my]sql on the environments where you need the migrated, fully-populated db. South sacrilege, I know, but worked for me.

EDIT - I'm putting a comment below at the top of this as it's important to read it before the > accepted answer that follows @andybak

@Dominique: Your advice regarding manage.py reset south is dangerous and may destroy the database if there are any third party apps using south in the project, as pointed out by @thnee below. Since your answer has so many upvotes I'd really appreciate it if you could edit it and add at least a warning about this, or (even better) change it to reflect @hobs approach (which is just as convenient, but doesn't affect other apps) - thanks! – chrisv Mar 26 '13 at 9:09

Accepted answer follows below:

First, an answer by the South author:

As long as you take care to do it on all deployments simultaneously, there shouldn't be any problem with this. Personally, I'd do:

    rm -r appname/migrations/ 
    ./manage.py reset south 
    ./manage.py convert_to_south appname 

(Notice that the “reset south” part clears migration records for ALL apps, so make sure you either run the other two lines for all apps or delete selectively).

The convert_to_south call at the end makes a new migration and fake-applies it (since your database already has the corresponding tables). There's no need to drop all the app tables during the process.

Here's what I'm doing on my dev + production server when I need to get rid of all these unneeded dev migrations:

1. Make sure we have the same DB schema on both sides
2. delete every migrations folder on both sides
3. run ./manage.py reset south (as the post says) on both sides = clears the south table *
4. run ./manage.py convert_to_south on both sides (faking 0001 migration)
5. then I can re-start to make migrations and push the migrations folders on my server

* except if you want to clean only one app among others, if so you'll need to edit your south_history table and delete only the entries about your app.