Detach latest migration #100
Conversation
|
I was a bit ambiguous initially planning to allow any migration to be detached. While detaching from the middle is do-able, it is less sensible to allow it, and it is not necessary for most common #91 scenarios. Doing multiple detaches of the top migration is sufficient, and adding support for re-attaching migrations is more important IMO. |
|
Ack on the review request. Will take a look tomorrow. |
|
Note two parts of #91 (comment) that I havent implemented yet is
and
The first of those is mandatory. IMO the second doesnt depend on "rejoin" being built first - all commands can be blocked until the detached migration has been removed - atm that means it is the users responsibility to do something with it or delete it. I'm happy to do that in the scope of this PR if you agree that is good enough for now. If any command is necessary whilst detached, IMO it is "detachmigration" so that the user can remove multiple migrations from the top, in order to reach a common branch point between two branches of development. |
|
I've added the ability to detect if there are detached migrations, but after looking through the existing list of commands I am reconsidering whether this is needed at all. While it might be usually a bad idea to run some of the commands when there is a detached migration, it cant cause new undesirable states which we must avoid, and maybe we should just let the user do the commands and let them deal with the repercussions. What might be useful is to always print the list of detached migrations, so they are not accidentally forgotten. |
|
I agree with your reconsideration -- it doesn't seem necessary to me to actually block operations for detached migrations. |
Step one of #91 - detach rather than unmake.