allod patch receive: a forge-less VM's host-provided checkout cannot be relayed back to the host #273

New issue

Closed

opened 2026-10-11 02:34:04 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-11 02:34:04 +01:00

Contributor

allod patch receive <vm>:<repo> <repo> cannot pull commits out of a host-provided checkout, which is every repository on a forge-less dev VM, the deployment the public install path produces first.

How a host-provided checkout is made (allod/nexus scripts/lib/host-provided-checkout.sh and bootstrap-vm): git init in the VM, then the host pushes its clone into it over SSH. The VM checkout therefore has no remote and no upstream.

What the relay does with that (cmd/allod/patch.go):

The export's resolve_default_base finds no upstream and no origin ref, so it exports from the root: every commit in the repository's history as a patch, after a git diff --check over the whole tree.
The apply side refuses a root export onto a destination that already has history: root export can only be applied to an empty destination history, exit 14. The host's clone always has history, since it is where the VM's copy came from.
Passing --base <host HEAD> makes the export one patch, but the apply side then refuses repo identity mismatch, exit 13: the manifest's source remote is empty and the destination's origin is the forge.

So neither the plain line nor the --base form works; the operator's only way to get work out of a forge-less VM is by hand.

Proposal:

receive passes the destination's HEAD to the export as a fallback base. The export uses it only when its own resolution (upstream, same-named origin branch, origin default branch) finds nothing and the commit exists in the source; a forge-backed VM is unaffected.
The identity check accepts an empty source remote when the base commit is present in the destination: shared history is the identity. A non-empty source remote that differs from the destination's is still refused.
tests/allod-patch.sh gains: a host-provided source (init, pushed into, no remote) with one new commit relays that one commit onto a destination clone that has an origin; a host-provided source whose history the destination lacks is refused naming the base; root export into an empty destination unchanged.

Found on the public install walk while planning the forge step, 2026-10-11: the dev VM's work must come back to the host before provision-vm --replace, and getting-started.sh --forge refuses the replace while it has not.

Part of allod/strategy#65.

`allod patch receive <vm>:<repo> <repo>` cannot pull commits out of a host-provided checkout, which is every repository on a forge-less dev VM, the deployment the public install path produces first. How a host-provided checkout is made (allod/nexus `scripts/lib/host-provided-checkout.sh` and `bootstrap-vm`): `git init` in the VM, then the host pushes its clone into it over SSH. The VM checkout therefore has no remote and no upstream. What the relay does with that (`cmd/allod/patch.go`): 1. The export's `resolve_default_base` finds no upstream and no `origin` ref, so it exports from the root: every commit in the repository's history as a patch, after a `git diff --check` over the whole tree. 2. The apply side refuses a root export onto a destination that already has history: `root export can only be applied to an empty destination history`, exit 14. The host's clone always has history, since it is where the VM's copy came from. 3. Passing `--base <host HEAD>` makes the export one patch, but the apply side then refuses `repo identity mismatch`, exit 13: the manifest's source remote is empty and the destination's `origin` is the forge. So neither the plain line nor the `--base` form works; the operator's only way to get work out of a forge-less VM is by hand. Proposal: - `receive` passes the destination's `HEAD` to the export as a fallback base. The export uses it only when its own resolution (upstream, same-named origin branch, origin default branch) finds nothing and the commit exists in the source; a forge-backed VM is unaffected. - The identity check accepts an empty source remote when the base commit is present in the destination: shared history is the identity. A non-empty source remote that differs from the destination's is still refused. - `tests/allod-patch.sh` gains: a host-provided source (init, pushed into, no remote) with one new commit relays that one commit onto a destination clone that has an origin; a host-provided source whose history the destination lacks is refused naming the base; root export into an empty destination unchanged. Found on the public install walk while planning the forge step, 2026-10-11: the dev VM's work must come back to the host before `provision-vm --replace`, and `getting-started.sh --forge` refuses the replace while it has not. Part of allod/strategy#65.

vnprc-agent commented

2026-10-11 15:53:02 +01:00

Author

Contributor

Landed on allod/tools master 01bf1da: receive passes the destination HEAD as the fallback base, an empty-remote source is accepted when the base commit is shared and the registry ids match. Pinned through the deploy template.

Landed on allod/tools master 01bf1da: receive passes the destination HEAD as the fallback base, an empty-remote source is accepted when the base commit is shared and the registry ids match. Pinned through the deploy template.

vnprc-agent closed this issue

2026-10-11 15:53:03 +01:00