I lead a project where we have frequent newcomers. on a few occasions they
encountered this message and the reason was always that they rebased their
feature branch on a new master, and the master brought a new migration
which conflicted with a new migration in the feature branch.
we generally don't see why we would want the merge migrations and advise
them to migrate to the common ancestor, rename their migration and change
the dependency, and then run migrate again. that's easy enough and the end
result is simpler.
i think makemigrations --merge matches well to a git workflow with
merging. in our project, we use rebasing instead, and there the merge
migrations don't make much sense.
I propose to change the message to {{{To fix them by creating a merge
migration, run 'python manage.py makemigrations --merge'}}} to make it
more clearer what will happen, and add {{{Alternatively, you can resolve
the conflict manually}}}.
an automatic solution could look like this: {{{mergemigrations --rebase
<number_of_migration_to_rebase>}}}, which would ask for confirmation
{{{this will rebase migration <name_of_migration_to_rebase> onto migration
<name_of_new_base_migration>}}}, or {{{this will set
<name_of_new_base_migration> as new dependency of
<name_of_migration_to_rebase>}}}.
--
Ticket URL: <https://code.djangoproject.com/ticket/28535>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:1>
* status: new => assigned
* owner: nobody => Masashi SHIBATA
Comment:
Hi! I implement this feature at:
https://github.com/django/django/compare/master...c-bata:ticket_28535?expand=1
I'll submit a PR after adding tests and refactoring.
So I assign this to myself.
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:2>
Comment (by Masashi SHIBATA):
I sent PR at:
https://github.com/django/django/pull/9131
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:3>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:4>
Comment (by karyon):
*bump* this needs a review.
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:5>
Comment (by Tim Graham):
Bump isn't helpful. There are 52 patches needing review at this time.
You're welcome to help. Use the PatchReviewChecklist and mark the ticket
as "ready for checkin" if it looks okay.
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:6>
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:7>
* type: Cleanup/optimization => New feature
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:8>
* version: 1.11 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:9>
* needs_docs: 1 => 0
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:10>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:11>
* stage: Ready for checkin => Accepted
Comment:
Sorry, but you are not supposed to set `Ready for checkin` for your own
patches.
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:12>
Comment (by Masashi SHIBATA):
Sorry I misunderstood the meaning of "Ready for Checkin". Thank you,
Claude Paroz.
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:13>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:14>
* status: assigned => closed
* resolution: => wontfix
Comment:
I don't think it's feasible to add `migrate --rebase` with more
complicated scenarios. We found many issues when testing only base use
cases. This would be complicated and error-prone.
--
Ticket URL: <https://code.djangoproject.com/ticket/28535#comment:15>