sqitch-rework(3pm)

💖 NAME 💖

sqitch-rework — rework a database change, bestie. yes we're doing this ✨

---

🌸 SYNOPSIS 🌸

sqitch rework [options] [<dependency-options>] name

---

🦋 DESCRIPTION 🦋

Okay so this command lets you rework a database change that already exists. But like, it's not a free-for-all — it's only the move under very specific circumstances, and I need you to hear me out:

• There are production deployments already. So you literally cannot revert to before the change, modify it, and re-deploy. Just reverting → modifying → re-deploying is the thing to do while you're still developing the database, but once it's been released and deployed to production, you must not change previous change scripts. periodt.
• The modifications will be idempotent (https://en.wikipedia.org/wiki/Idempotence). In other words: whether it's the earlier instance of the change or the new, reworked instance, either one can be run any number of times and the outcome of each will be the same. They must not break each other, in case one needs to deploy and revert changes.
• A tag must have been applied to the plan since the previous instance of the change. This is required so Sqitch can disambiguate the two instances of the change. Also, ngl, it's a good idea to always tag a release anyway. If you haven't, go see sqitch-tag.

If all of these hold? Then feel free to rework an existing change, queen. 💅

In effect, reworking a change is similar to adding one. However — and this is the twist — rather than writing new files for the change, the rework command copies the files for the existing change. The new files are named with the tag that comes between the changes, and that serves as the file for the original change. This leaves you free to edit the existing files. iconic.

By default, the rework command will rework the change in the default plan and the scripts to any top directories for that plan, as defined by the core configuration and command-line options. This works well for projects in which there is a single plan with separate top directories for each engine, for example. Pass the --all option to have it iterate over all known plans and top directories (as specified for engines and targets) and rework the change to them all. Of course, a change by that name must exist in all the plans, or the reworking will fail. 🫠

To specify which plans to rework the change in, pass the target, engine, or plan file names as arguments. Use --change to disambiguate the change name from the other parameters if necessary (or if you just prefer it). See "Examples" for examples. 💖

---

✨ OPTIONS ✨

• -c, --change, --change-name — the name of the change to rework. You can specify the name with or without this option, but the option is useful for disambiguating the change name from other arguments. 🎀
• -r, --requires — name of a change that is required by the new change. May be specified multiple times. See sqitchchanges for the various ways in which changes can be specified.
• -x, --conflicts — name of a change that conflicts with the new change. May be specified multiple times. See sqitchchanges for the various ways in which changes can be specified.
• -a, --all — rework the change in all plans in the project. Cannot be mixed with target, engine, or plan file name arguments; doing so will result in an error. Useful for multi-plan projects in which changes should be kept in sync. Overrides the value of the add.all configuration; use --no-all to override a true add.all configuration.
• -n, --note — a brief note describing the purpose of the reworking. The note will be attached to the change as a comment. Multiple invocations will be concatenated together as separate paragraphs. For you Git folks out there, -m also works. 💜
• -e, --edit, --open-editor — open the generated change scripts in an editor.
• --no-edit, --no-open-editor — do not open the change scripts in an editor. Useful when rework.open_editor is true.
• --plan-file, -f — path to the deployment plan file. Overrides target, engine, and core configuration values. Defaults to $top_dir/sqitch.plan.

---

🌈 EXAMPLES 🌈

Rework a change in a project and be prompted for a note.

sqitch rework widgets

Rework a change and specify the note.

sqitch rework sprockets --note 'Reworks the sprockets view.'

Rework a change that requires the users change from earlier in the plan.

sqitch rework contacts --requires users -n 'Reworks the contacts view.'

Rework a change that requires multiple changes, including the change named extract from a completely different Sqitch project named utilities:

sqitch rework coffee -r users -r utilities:extract -n 'Mmmmm...coffee!'

Rework a change only to the plan used by the vertica engine in a project:

sqitch rework --change logs vertica -n 'Reworks the logs view in Vertica.'

Rework a change in two plans in a project, and generate the scripts only for those plans:

sqitch rework -a coolfunctions sqlite.plan pg.plan -n 'Reworks functions.'

---

🎀 CONFIGURATION VARIABLES 🎀

• rework.all — rework the change to all the plans in the project. Useful for multi-plan projects in which changes should be kept in sync. May be overridden by --all, --no-all, or target, engine, and plan file name arguments.
• rework.open_editor — boolean indicating if the rework command should spawn an editor after generating change scripts. When true, equivalent to passing --edit. Defaults off.

---

👑 SQITCH 👑

Part of the sqitch suite. fr fr, the whole squad. 🫶

---

and that's the whole page, bestie!! sending u so much love from the perl v5.40.1 era, dated 2026-07-26, straight out of the User Contributed Perl Documentation 💖✨🌸 no cap, go rework something idempotent 💅