rebase-migration: Make it possible to handle chains of migrations.

[roanster007]

Commit 1:
Previously, the rebase_migration command was not able to rebase chains of migrations in a single app.

This commit introduces a new flag -- "--new" which basically is used for the first migration you create in a commit , and it wipes out your migration history in max_migration.txt, and writes up that first migration in the first line. Any further migrations added without the flag are simply added under each other in the max_migration.txt.

This would allow the rebase_migration command to access the chain of migrations that need to be rebased in a commit, and will rebase them accordingly.

eg: ./manage.py makemigrations --new in your new commit would wipe out the existing list in max_migration.txt and write up the first migration created in the first line. Subsequent migrations don't require you to add this flag, and they are added under each other in the max_migration.txt.

While rebasing, self.last_migration_number would be initialized to the last merged migration, and based on these rebased migrations are renumbered, and eventually self.last_migration_number is updated.

Added necessary tests, and also tested manually in a project requiring rebasing of 3 migrations in an app.

Fixes #27

cc @timabbott

[roanster007]

@adamchainz we are thinking of using this in @zulip. Since we would be quite often making multiple migrations in same app in a commit this feature would be important for us. Let me know what you think about this PR/approach. Thanks!

[roanster007]

@adamchainz Also added a commit, which would fix #184 (unapplies and rebases the migrations rather than throwing out error if migrations that need to be rebased are already applied) Extracted it to a separate PR in #346

[adamchainz]

Thank you for your work here and in the other PR. I haven't found the time to review it fully yet. Here are some initial thoughts.

I think --new is going to be rather error-prone. It requires the developer to remember the flag right at the start of the PR.

Putting multiple migration names in max_migration.txt is also error prone, I think. If branches have common migration names in the middle, Git will not output an easy-to-parse single merge conflict, but multiple. I think we should instead be able to chain of to-rebase migrations from the conflict information itself, by going backwards to the common ancestor of
the two branches.

Anyway, I will try have a play around with the PR soon. I have been doing some other updates here so a bit more familiar with the code right now.

[roanster007]

@adamchainz Thanks for responding! Your thoughts are absolutely make sense.

Thinking about this a bit more, I could come up with a modified approach which might address your concerns. Please let me know your thoughts!

1. --new flag:

Essentially the point of --new flag was to track the migrations introduced by user in that specific branch only.

Since this might however add additional burden on users to add the flag, we can probably use local Branch-specific git config, which sets up a flag migrationCreated to true when user calls makemigrations for the first time (i.e., value of that config variable is not yet defined / false):

create the variable

git config branch.$(git rev-parse --abbrev-ref HEAD).migrationCreated true

get the variable value

git config --get branch.$(git rev-parse --abbrev-ref HEAD).migrationCreated

2. Putting multiple migration names in max_migration.txt is also error prone

We can maybe leave the max_migration.txt as it is, and probably introduce a new file -- migrations_list.txt. This file is basically populated with every migration user introduces in that branch.

So when user rebases this branch, the workflow when user does rebase-migrations can be like:

• make note of the rebased max migration number.
• Accept all incoming changes in migrations_list.txt:

git checkout --ours migrations_list.txt

• Now iterating through migrations_list, update the migration number, starting from rebased max migration number + 1.