Ah right, thanks for elaborating. I normally stick with a single app and a linear migration history. Avoiding merge migrations is good for a number of reasons and avoids the situation your diagram covers - see my recent package django-linear-migrations which help with that: https://adamj.eu/tech/2020/12/10/introducing-django-linear-migrations/ .
In general though app interdependencies and irreversible migrations complicate this, as James says. There’s a tool for using DB “snapshots” locally to save/restore DB state when switching branches - it’s called stellar: https://github.com/fastmonkeys/stellar . I think this is the only way to be reliable. If we were going to make something like this that is Django specific, we’d normally want to have a working, battle-tested third party implementation before considering merging it to core. On Thu, 17 Dec 2020 at 00:36, Roman Odaisky <rday...@gmail.com> wrote: > On Thursday, 17 December 2020 02:28:02 EET James Bennett wrote: > > On Wed, Dec 16, 2020 at 1:39 PM Adam Johnson <m...@adamj.eu> wrote: > > >> manage.py migrate app 0050_migration_from_master will unapply too much > > >> (specifically, all the subsequent migrations from master)> > > > I don't follow you. This is exactly the thing I do, migrating back to > the > > > last common migration. > > I think the issue being described is if other apps have migrations > > that *should* be applied in the main branch, but would be unapplied by > > migrating back to app/0050. So migrating to app/0050 does not actually > > restore the state the main branch expected. > > Suppose all these are currently applied: > > master ...---0050---0051a---0052a > \ \ > feature 0051b---0052b---0053m---0054b > > The issue is about unapplying 0054b, 0053m, 0052b and 0051b while not > touching > the master migrations. Let’s ignore possible dependencies from other apps > for > now. > > > I'm also not sure this is a thing that Django can automate in any way > > that's likely to be reliable; too many migrations in large projects > > have complex interdependencies, a lot of migrations aren't reversible, > > etc. > > Django will happily reverse all the way to 0051b without giving any > thought to > the above concern. The only thing it won’t do is unapply that one last > migration. Why can’t we add that one step? > > > -- > 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/2075285.l7tNb9eccj%40xps > . > -- Adam -- 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/CAMyDDM0%2BNJCnxSLxhJQ%2ByfEykVHaq3ez4Onnh1-sUme3CojsAg%40mail.gmail.com.
