> 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.
Let me try to reformulate it in different terms.
It’s not about some new big workflow.
It’s not about
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/2
On Thursday, 17 December 2020 02:28:02 EET James Bennett wrote:
> On Wed, Dec 16, 2020 at 1:39 PM Adam Johnson 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
On Wed, Dec 16, 2020 at 1:39 PM Adam Johnson 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 t
On Wednesday, 16 December 2020 23:38:55 EET Adam Johnson 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 migra
ote:
> Hi All,
>
> I would like to solicit some further comments regarding #32267. The main
> question is:
>
> Should Django support unapplying migrations in a branch?
>
> Typical use case:
> $ git switch otherdeveloper/feature
> $ manage.py migrate
> Applying app.0
Hi All,
I would like to solicit some further comments regarding #32267. The main
question is:
Should Django support unapplying migrations in a branch?
Typical use case:
$ git switch otherdeveloper/feature
$ manage.py migrate
Applying app.0051_migration_from_feature... OK
Applying app
