Finally, remove_columns and remove_column are no longer aliases and the interface of remove_column is changed to accept only one column (along with new arguments that are used in case of reversal).

The PR builds on #8177 (itself building on #7627), but the need they all fulfill is independent. Each PR can be accepted/rejected independently. I hope all three can be accepted as they nicely complement each other and give powerful means to create reversible migrations. The ChangeLog remains to be updated, but I'll wait until confirmation that this will be merged.

This comment has been minimized.

@steveklabnik@tenderlove With all due respect, this is a terrible rationale. Not only is backporting/reverting rare, but git revert and git cherry-pick accept ranges of commits.

Squashing is lossy, the commits I'm submitting are atomic and make it easier to understand what's going on, for example if anyone does a git blame at some point.

Finally, if you decide to revert part of this (e.g. make drop_table revertible), you won't be able to if the commits are squashed. Similarly, the first commits are simple code improvements made because I noticed things while doing my changes.

These commits total over 1000 line changes in total, I don't see a problem in them being split in a bunch of atomic commits.

If you want me to open 13 different pull requests, I will, or maybe the commit messages should refer to this PR, but I won't squash these commits. Of course, you guys are free to do it yourself if you feel that's the way it should be.

@steveklabnik@tenderlove With all due respect, this is a terrible rationale. Not only is backporting/reverting rare, but git revert and git cherry-pick accept ranges of commits.

Squashing is lossy, the commits I'm submitting are atomic and make it easier to understand what's going on, for example if anyone does a git blame at some point.

Finally, if you decide to revert part of this (e.g. make drop_table revertible), you won't be able to if the commits are squashed. Similarly, the first commits are simple code improvements made because I noticed things while doing my changes.

These commits total over 1000 line changes in total, I don't see a problem in them being split in a bunch of atomic commits.

If you want me to open 13 different pull requests, I will, or maybe the commit messages should refer to this PR, but I won't squash these commits. Of course, you guys are free to do it yourself if you feel that's the way it should be.

This comment has been minimized.

@carlosantoniodasilva Right. I still can't imagine why it causes a problem on mysql, but I'll just not use transaction at all. Actually I can probably use send something :tap instead. Anyways, I'll run the test when I'm home tomorrow and send a PR.

@carlosantoniodasilva Right. I still can't imagine why it causes a problem on mysql, but I'll just not use transaction at all. Actually I can probably use send something :tap instead. Anyways, I'll run the test when I'm home tomorrow and send a PR.