Unlanded-branch backup (nightly copy of work that is not on master)

Why this exists

A branch that was never pushed and never merged lives in exactly one place: the git store on the computer that made it. Delete that branch by mistake, or lose the disk, and the work is gone with no copy anywhere. This job is the copy. It is deliberately not a copy of the whole repository — copying the whole thing every night would be hundreds of megabytes of history you already have — it is a copy of precisely the commits master does not already contain.

What it does each night

1. Lists the unlanded branches — every local branch whose tip master cannot already reach. A branch whose work has already gone into master contributes nothing and is left out; its name is left out too.
2. Picks a destination on a different physical disk, not merely a different drive letter. This distinction is the whole point: on many computers a second letter is a second partition of the same disk, so a copy there dies with the original. Where the machine will not say which physical disk a volume is on, the job declines to guess and skips (see When it skips, below).
3. Writes one bundle — a single file that carries the unlanded commits and their branch names.
4. Verifies it — the file is read back and must be a valid bundle, and the branch names it declares must be exactly the set it planned. Only then is it given its real name; a file that fails either check is deleted on the spot, so a half-written or broken bundle is never left where a restore would find it.
5. Writes a small sidecar beside the bundle recording the master commit it was cut against, how many branches it holds, its size, and the verification result.
6. Prunes — the newest seven nights are kept and older ones are deleted. It deletes only files it wrote itself, inside its own folder; anything else in there is left alone.

Where the copy goes

Automatically, onto the mounted volume with a different physical disk, remembering the choice so the destination never moves between nights. The folder is:

<that disk>\AMC-Unlanded-Branch-Backup\<your repository name>\
    unlanded-2026-10-11.bundle     ← one night's copy
    unlanded-2026-10-11.json       ← what it holds and which master it was cut against

If you want it somewhere specific instead, name that folder and the job uses it exactly as given:

AMC_UNLANDED_BACKUP_DIR = L:\my-backups

When it skips

A computer with only one disk is skipped, not faked. Writing the copy to a second partition of the same disk would give you the feeling of a backup that would not survive the disk dying, so the job refuses, records a completed run, and raises one notice saying why. Attach a second drive and the next night starts copying on its own — there is nothing to switch on. That notice appears once per computer, not every night.

The same skip happens on any machine where the operating system will not say which physical disk a volume belongs to. That is deliberate: a copy that only looks safe is worse than a visible gap.

Getting a branch back

You need a repository that already contains the master commit named in the sidecar — that is what the bundle was cut against, and it is normally the very repository the copy came from. Then, per branch:

git fetch <path-to-bundle> <branch>:<branch>

For example:

git fetch C:\AMC-Unlanded-Branch-Backup\agent-orchestrator\unlanded-2026-10-11.bundle \
          work/my-feature:work/my-feature

Check it landed the tip you expected:

git log -1 --format=%H work/my-feature

That commit should match the sidecar's recorded tip for that branch. Nothing is overwritten — if the branch already exists under that name, fetch the bundle version under a new name (work/my-feature:recovered/my-feature) and compare.

The one limitation worth knowing

Because the bundle is cut against a named master commit, a restore needs that commit to be present. If you are restoring onto a computer whose repository is older than the recorded master commit, fetch master first — or take the whole repository from the separate off-drive store copy — and then fetch from the bundle. git bundle verify <file> tells you exactly which commits a bundle needs before you try.

A note on two other things it is not

• It is not a copy of the repository's history. For that there is a separate job that keeps a copy of the whole git store on another drive, so a destroyed store can be restored in one command.
• It never writes anything into the repository. No branch, ref, worktree or config entry is created, moved or deleted by this job — it reads git and writes only to its own folder on the other disk.

Turning it off

The job is on by default, for every developer, with nothing to configure. Its row is AMC-unlanded-branch-backup, visible with every other scheduled job at GET /ops/jobs on the local control server, and switching that row off is the one switch — the same switch every scheduled job has. Its readout there carries what the last run did: outcome=ok branches=… bundleKB=… verify=ok master=….