Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install Django Linear Migrations package. #215

Closed
3 of 4 tasks
ExperimentsInHonesty opened this issue Oct 13, 2023 · 3 comments · Fixed by #217
Closed
3 of 4 tasks

Install Django Linear Migrations package. #215

ExperimentsInHonesty opened this issue Oct 13, 2023 · 3 comments · Fixed by #217

Comments

@ExperimentsInHonesty
Copy link
Member

ExperimentsInHonesty commented Oct 13, 2023

Overview

We want to install this package to ensure your migration history is linear and help us with merge conflicts.

Action Items

Resources/Instructions

https://github.com/adamchainz/django-linear-migrations

@fyliu fyliu self-assigned this Oct 16, 2023
@fyliu
Copy link
Member

fyliu commented Oct 16, 2023

I'm taking this issue since it's better to have it sooner rather than later.

The setup is straightforward from the readme.
I had to set it up on both main and the incoming feature branch for merging. It only works if the check file max_migration.txt exists in both branches to create the conflict condition.

It doesn't prevent the conflict but it makes it appear in git, which is more convenient than the way we have it currently, which is in a pre-commit hook.

After the conflict happens on the git rebase, the rebase_migration command puts the incoming migration file at the end of the migration chain.

I'm not sure how this can be tested best. I can create the pre-rebased and then the reviewer can check that the rebase creates a conflict and that the rebase_migration command will resolve the conflict the way it should.

@fyliu
Copy link
Member

fyliu commented Oct 19, 2023

I'm down to the last reviewable PR #216. The commit with the migration file must be AFTER the django-linear-migrations setup. So I would need to insert the setup commit before Alex's PR code and then update his commit with a newly-generated max_migration.txt file. At that point, Alex's code will have a 0017 and main will have a different 0017. Rebasing them will create a git merge conflict, and running manage.py rebase_migration core should fix it automatically.

@fyliu
Copy link
Member

fyliu commented Oct 19, 2023

Steps to show this working:

# add fang's fork as a remote
git remote add fang https://github.com/fyliu/peopledepot.git

# fetch from remote
git fetch fang

# delete the db volume
docker-compose down -v

# Checkout the dlm-1-main branch
git checkout fang/dlm-1-main

# run buildrun.sh
./scripts/buildrun.sh

# checkout the dlm-2-feature-branch
git checkout fang/dlm-2-feature-branch

# create a review branch
git checkout -b review

# run git rebase dlm-1-main
git -c rerere.enabled=false rebase fang/dlm-1-main

# run rebase_migration to fix the conflict
docker-compose exec web python manage.py rebase_migration core

At this point, the conflicting migration file should be successfully renamed and the references updated. The only thing left to do is to add and commit the fix as an amended commit.

git add .
git commit --amend --no-edit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: ✅Done
Development

Successfully merging a pull request may close this issue.

2 participants