Syncing and removing

sync#

ddev branchery database:sync <name> [--from=<worktree>] · POST /api/worktrees/<name>/sync

Replaces the worktree's data with the project checkout's, or another worktree's. The code is not touched, and neither are files outside what data.needs names.

1. Copying <source> into <target>. How far this branch is behind the source is reported first, because that is what explains errors afterwards. The dump is taken, then the target is dropped and made anew, then the dump is loaded — in that order, so a dump that fails leaves the old data where it was.
2. Putting the addresses back. Site configuration the branch does not keep under version control comes along from the source, and every https://….ddev.site in it is rewritten to this worktree's address. A committed one is left as it is, with a line in the log; see Data source and site addresses.
3. Fitting the data to this code (config migrate).
4. Flushing caches (config).

remove#

ddev branchery worktree:remove <name> · DELETE /api/worktrees/<name>

1. Removing database. DROP DATABASE IF EXISTS branchery_<name>.
2. Removing worktree. git worktree remove --force, the directory, and the branch the worktree is on (git branch -D) — for a worktree that has wandered onto a patch, the patch's branch and not the one it was made for, which the question before the press names. Where git refuses the worktree -- one holding a submodule, or a locked one — the directory goes anyway and the stale entry is pruned. A branch git will not delete ends the operation as failed, after the cleaning up.
3. Cleaning up. Docroot link, metadata, PHP pool assignment, the ddev describe block, and the worktree's operation history. Only the removal's own log stays, until the name is used again.

The list offers finished worktrees — branches merged into the project's own, and branches deleted from the remote — for removal together, which is this operation once per worktree. Nothing with uncommitted work in it is offered.