Proposal: `sqitch reset` command for removing undeployed changes

[placetobejohan]

Problem Statement

In development, it's common to add multiple changes with sqitch add, then later decide some are unnecessary. Currently, removing undeployed changes requires:

1. Editing sqitch.plan manually.
2. Deleting the corresponding deploy, revert, and verify scripts.
3. (If applicable) Removing from version control.

This process could be streamlined with a sqitch reset command, modeled after git reset.

Proposed Behavior

• sqitch reset (without arguments)

  • Resets to the last deployed change.
  • Removes all undeployed changes from sqitch.plan.
  • Deletes their SQL files.

• sqitch reset <change>

  • Resets to the specified <change>.
  • Tries to remove all changes after <change>.
  • Checks only the development database to determine if any of those changes are deployed.
  • Blocks removal if any of those changes are already deployed, displaying an error:

    "Change <next_change> is deployed on <target>. Run sqitch revert <target> -to <previous_change> first."

This ensures that changes aren’t removed while still deployed, preventing inconsistencies.

Future Enhancements

Options like --soft (keep SQL files) and --hard (also remove from VCS) could be considered later.

Would this be useful for others? Feedback is welcome!

[theory]

I like this idea, but want to point out that there can be more than one target, including targets not in the sqitch.conf. So I'm not sure how worthwhile it is to check that changes haven't been deployed.

[placetobejohan]

Right, I was only considering the case where the development database is set as the default target. Then it would make sense to include a check IMO, just to make sure that all changes that will be deleted have been reverted.

I've added that to the proposal (only check the dev db) plus I've also remodeled sqitch reset to look more like how git reset works.

I guess there could be an issue if the check is done against the wrong database. But isn't it the user's responsibility to select the correct target?

[theory]

FWIW git reset does not look to see if discarded changes are pushed. That said, if they're not, Git still keeps them until you git gc, so you can always restore them later. Not an option with Sqitch, but your SCM (Git) should be a reasonable failsafe.

[placetobejohan]

The way I see it the git analogy doesn't fully hold here since sqitch deploy is equivalent to git commit and git push together.

Considering only git commit, perhaps it would make sense to first revert the deployed changes (like how git reset undoes commits) and then delete the associated files (similar to how git reset would clean up working directory changes).

Here’s how the updated flow of sqitch reset would look:

1. Revert the deployed changes: if any changes have been deployed, they are reverted first.
2. Remove the changes from sqitch.plan: clean up the plan by removing entries for the reset changes.
3. Delete the corresponding SQL files: remove the deploy, revert, and verify SQL files associated with those changes.

[placetobejohan]

I've given this some more thought, it probably makes more sense implement sqitch clean - remove undeployed changes. In this way the user is still responsible for doing a sqitch revert first.

sqitch reset could then also be added as a combination of revert and clean, similar to sqitch rebase.

What do you think? @theory

[theory]

I like the idea. Is this something you think you could work on, @placetobejohan?

[placetobejohan]

Yes, I'm new to Perl but I can give it a go.