Open jdavisclark opened 10 years ago
looks like status
and compare
actually behave properly.
Looks like all the funky behavior is controlled by Mite.stepTo
, and shouldn't require any changes outside of there.
Maybe it should warn about it and require that you provide the -f in order to ignore the warning?
agreed, sounds like the best way to handle it.
Need a better way to handle the instance where migration-7 is executed and migration-5 is unexecuted. This starts to become an issue as soon as you have multiple active feature branches, multiple developers, multiple qa/uat environments, etc...
The idea is that when you get in this migration execution state, there is no way that the unexecuted migration could have any way of being dependent on anything after it that didn't exist in its branch. So, its super funky, but really isn't a problem so long as we handle it gracefully.