Clarify migrate --fake documentation

[Ramez Kabbani]

​migrate documentation implies that running migrate --fake on a specific migration toggles its applied status (applied => unapplied and vice versa). The reality is that one needs to run migrate --fake on the preceding migration to mark the migration as unapplied.

[Tomer Chachamu]

Agreed it could be clearer.

[tothegump]

What about:
Tells Django to mark the migrations before and including this <migrationname> as having been applied, meanwhile mark the migrations after this <migrationname> as having been unapplied?

But it is not concise.

[Israel Saeta Pérez]

Replying to tothegump:

What about:
Tells Django to mark the migrations before and including this <migrationname> as having been applied, meanwhile mark the migrations after this <migrationname> as having been unapplied?

But it is not concise.

What about:
Tells Django to mark the migrations up to the target one (following the rules described above) as applied, but without actually running the SQL to change your database schema.

IMO the source of confusion could be the or unnaplied in the description. But after having read the behavior rules above for the second argument and the meaning of the word fake itself I believe it is pretty clear.

[Senthil]

​https://github.com/django/django/pull/9610

[Tim Graham <timograham@…>]

In cbac11f9:

Fixed #28784 -- Clarified how migrate --fake works.

[Tim Graham <timograham@…>]

In d06381d:

[2.0.x] Fixed #28784 -- Clarified how migrate --fake works.

Backport of cbac11f9624d529809e9bdaa7f4d3ab2c5e93009 from master