The first case is definitely a source of friction for me too. Django management commands could help but it's still up to the developer to remember to run them. I'd prefer to have the VCS identify and help resolve these situations right when they arise.
The second case seems to be discouraged by the docs: "you are encouraged to make migrations freely and not worry about how many you have". Following this guideline, it will only be in rare situations that already applied migrations will be modified. Therefore I don't see a need for framework support in resolving this. Back to the VCS idea.... and as an aside to Django development: Looking at the git docs, a post-checkout script could compare the two branches and provide a warning about any change to the migrations in the working tree. Looks like others have thought down the same lines: - https://stackoverflow.com/questions/32682293/django-migrations-workflow-with-multiple-dev-branches - https://cheesecakelabs.com/blog/really-annoys-django-migrations/ I think I'll look into adapting the post-checkout hook in this gist <https://gist.github.com/lyrixx/5867424>, which differences in PHP `composer.lock` files. Dwight -- On Sunday, July 5, 2020 at 5:36:16 AM UTC+2 Lorenzo Peña wrote: > See if this solves part of the problem > https://github.com/lorinkoz/django-unmigrate > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/40bb69f4-4a8f-40ce-8e3e-73369451134dn%40googlegroups.com.
