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).

account#

ddev branchery worktree:account <name> · POST /api/worktrees/<name>/account

Makes this worktree an administrator whose password is known: its own name, and the password the project names — #Password1 where it names none. Nothing else about the worktree is touched.

A worktree that inherited a database inherited the accounts in it, and their passwords belong to whoever set them; a fresh installation has one this made already. So the page states a login only where there is one to state, and offers this where there is not.

1. Making an account (config account). What that means is the project's, and the shipped TYPO3 profiles drop an account of that name first — the core refuses a username that is taken and has no command that changes one it finds, so a second press would otherwise fail on what the first made.

Offered only where the configuration says how an account is made here, and never on the project's own checkout: that database is the developer's, not a copy.

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.