Fixed #25390 -- Allowed specifying a start migration in squashmigrations

Thanks Tim Graham for the review.

docs/ref/django-admin.txt

@@ -1049,8 +1049,8 @@ of sync with its automatically incremented field data.
 The :djadminopt:`--database` option can be used to specify the database for
 which to print the SQL.
 
-squashmigrations <app_label> <migration_name>
----------------------------------------------
+squashmigrations <app_label> [<start_migration_name>] <migration_name>
+----------------------------------------------------------------------
 
 .. django-admin:: squashmigrations
 
@@ -1059,6 +1059,13 @@ down into fewer migrations, if possible. The resulting squashed migrations
 can live alongside the unsquashed ones safely. For more information,
 please read :ref:`migration-squashing`.
 
+.. versionadded:: 1.9
+
+When ``start_migration_name`` is given, Django will only include migrations
+starting from and including this migration. This helps to mitigate the
+squashing limitation of :class:`~django.db.migrations.operations.RunPython` and
+:class:`django.db.migrations.operations.RunSQL` migration operations.
+
 .. django-admin-option:: --no-optimize
 
 By default, Django will try to optimize the operations in your migrations

docs/releases/1.9.txt

@@ -473,6 +473,9 @@ Migrations
   applied and others are being unapplied. This was never officially supported
   and never had a public API that supports this behavior.
 
+* The :djadmin:`squashmigrations` command now supports specifying the starting
+  migration from which migrations will be squashed.
+
 Models
 ^^^^^^
 

docs/topics/migrations.txt

@@ -572,7 +572,7 @@ possible depends on how closely intertwined your models are and if you have
 any :class:`~django.db.migrations.operations.RunSQL`
 or :class:`~django.db.migrations.operations.RunPython` operations (which can't
 be optimized through) - Django will then write it back out into a new set of
-initial migration files.
+migration files.
 
 These files are marked to say they replace the previously-squashed migrations,
 so they can coexist with the old migration files, and Django will intelligently