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 Tim Graham, 7 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Masashi SHIBATA, 7 years ago

Owner: changed from nobody to Masashi SHIBATA
Status: newassigned

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.

Version 0, edited 7 years ago by Masashi SHIBATA (next)

comment:4 by Masashi SHIBATA, 7 years ago

Has patch: set

comment:5 by karyon, 7 years ago

*bump* this needs a review.

comment:6 by Tim Graham, 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 Carlton Gibson, 7 years ago

Needs documentation: set

comment:8 by Masashi SHIBATA, 5 years ago

Needs tests: set
Type: Cleanup/optimizationNew feature

comment:9 by Masashi SHIBATA, 5 years ago

Version: 1.11master

comment:10 by Masashi SHIBATA, 5 years ago

Needs documentation: unset
Needs tests: unset

comment:11 by Masashi SHIBATA, 5 years ago

Triage Stage: AcceptedReady for checkin

comment:12 by Claude Paroz, 5 years ago

Triage Stage: Ready for checkinAccepted

Sorry, but you are not supposed to set Ready for checkin for your own patches.

comment:13 by Masashi SHIBATA, 5 years ago

Sorry I misunderstood the meaning of "Ready for Checkin". Thank you, Claude Paroz.

comment:14 by Mariusz Felisiak, 5 years ago

Patch needs improvement: set

comment:15 by Mariusz Felisiak, 5 years ago

Resolution: wontfix
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top