Closed perrito666 closed 1 year ago
I've run into the same inconvenience when merging branches that each have migrations, and I would like to improve the process.
If I understand your proposal correctly given a situation where there existed the following migrations:
001_create_foo.sql
001_create_bar.sql
Then you would run the command:
tern update 001_create_bar.sql
And it would rename 001_create_bar.sql
to 002_create_bar.sql
.
I like the idea of tooling to solve this problem. This is a improvement over:
mv {001,002}_create_bar.sql
The update command figures out what the next available migration is -- but I think more can be done.
Here's a few rough ideas of other potential solutions.
An interactive mode that shows all duplicates and the user chooses which one to renumber. This would save a lot of time and typing when their are multiple duplicate migrations to merge.
Some sort of integration with git. In theory it should be possible tell tern which branches are being merged and it to figure out what to rename. OTOH, that is tied to git and it might be difficult to handle all the merge and rebase strategies people use.
We could have 2 commands designed to work together. The first command captures what the current migrations are. Then the second command finds all the new duplicates and renames them. e.g.
tern renumber_duplicates start
git merge feature-branch-with-migrations
tern renumber_duplicates finish
tern could persist state in a temp file.
I think ideas 1 and/or 3 would be even easier to use than the update
command as is.
I suspect 1 would be the more agnostic. It would fit most scenarios. We could alternatively add a flag so people that don't want interactive can just pass the ones they want forward migrated. Ill work something and come back so we can see if it goes in the right direction :)
edit: (sorry just realized that I had used the wrong number so I changed it so my comment makes sense)
did not forget about this, just life got in the middle, ill come back to this soon
lol, i came back to finally address this and found that you already implemented a way better version in v2 :) sorry for dragging for so long and thank you for the amazing addition
update sub-command
Rationale
Oftentimes many of us in the same project add migrations using tern as a tool and, upon merging one pull request, all others need to update the number of their proposed patches. This is something that might happen more if one is working in a long lived branch.
Proposed solution
I added an
update
command which allows to re-number an existing migration.Collateral additions