Opened 7 years ago
Closed 5 years ago
#28535 closed New feature (wontfix)
Message on conflicting migrations is misleading for rebase workflows
Reported by: | karyon | Owned by: | Masashi SHIBATA |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
When there are conflicting migrations, it says
Conflicting migrations detected; multiple leaf nodes in the migration graph: (%s). To fix them run 'python manage.py makemigrations --merge'
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>
.
Change History (15)
comment:1 by , 7 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 7 years ago
Has patch: | set |
---|
comment:6 by , 7 years ago
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.
comment:7 by , 7 years ago
Needs documentation: | set |
---|
comment:8 by , 5 years ago
Needs tests: | set |
---|---|
Type: | Cleanup/optimization → New feature |
comment:9 by , 5 years ago
Version: | 1.11 → master |
---|
comment:10 by , 5 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
comment:11 by , 5 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:12 by , 5 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
Sorry, but you are not supposed to set Ready for checkin
for your own patches.
comment:13 by , 5 years ago
Sorry I misunderstood the meaning of "Ready for Checkin". Thank you, Claude Paroz.
comment:14 by , 5 years ago
Patch needs improvement: | set |
---|
comment:15 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
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.
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.