54 lines
3.4 KiB
Markdown
54 lines
3.4 KiB
Markdown
---
|
|
name: live-checkout-landing-chain
|
|
description: "Prove whether a merged change is actually deployed in ~/.omp: walk origin/main vs the checked-out main commit vs the worktree, then fast-forward in place — git refuses fetch into a checked-out branch, and a running harness caches its config."
|
|
---
|
|
|
|
## When to use
|
|
|
|
The user says a merged/committed change is "not there" (`/switch` can't see a model, a doc is missing, a config edit is invisible) while the repo work itself is green. In a repo where **the checkout is the deployment** (`dank/command-center` at `~/.omp`), "merged" and "deployed" are different commits — measure both before believing either claim.
|
|
|
|
## The ladder — read all four levels, in order, before answering
|
|
|
|
```bash
|
|
cd ~/.omp && git rev-parse HEAD origin/main # 1+2: deployment vs forge
|
|
git ls-tree --name-only HEAD # is the file even in HEAD?
|
|
git worktree list # 3: which worktree am I in vs main?
|
|
```
|
|
|
|
1. `origin/main` — the forge truth (`gh`/`tea` absent; Gitea API or a fetch).
|
|
2. `/home/blank/.omp` HEAD — **what the running agent actually reads.** Merged PR at `3eb1ada` while this sat at `53025a6` is the whole bug.
|
|
3. The feature/session worktree — where the edit was authored; its files can be correct while main is stale, which is why the author sees the change and the user does not.
|
|
4. The running process — `models.yml` / `config.yml` are read at startup and cached for the process lifetime; an open session needs a restart even after level 2 is correct.
|
|
|
|
Belt-and-braces when the answer hinges on file contents, not just commit ids: parse the live file (`python3 -c "import yaml; ..."` for `agent/models.yml`, or grep the doc) rather than inferring from `git log`.
|
|
|
|
## Landing main without touching the tree
|
|
|
|
`git fetch origin main:main` **fails**: `fatal: refusing to fetch into branch 'refs/heads/main' checked out at '/home/blank/.omp'`. The fetch-into-ref trick only works for branches that are *not* checked out anywhere.
|
|
|
|
For a checked-out main, prove then fast-forward:
|
|
|
|
```bash
|
|
git merge-base --is-ancestor main origin/main && echo "ff possible"
|
|
git merge --ff-only origin/main # no rebase — Frank dislikes history rewrites
|
|
```
|
|
|
|
`--ff-only` is the safe verb on a dirty main checkout: tracked-file commits (the live-sync tier) and runtime dirt (`agent/memories/*/state.json`, `dotfiles/**`) survive untouched, and it cannot rewrite history. Confirm the dirt is still there afterwards — if it vanished, something else clobbered the tree.
|
|
|
|
## The heartbeat is not instant
|
|
|
|
`scripts/live-sync.sh` (systemd user timer, hourly) is what normally advances main. Check its cadence rather than assuming it ran:
|
|
|
|
```bash
|
|
systemctl --user status live-sync.timer --no-pager # "Trigger: …" = next beat
|
|
systemctl --user status live-sync.service --no-pager # "since …" = last run
|
|
```
|
|
|
|
A merge made minutes after the last beat waits until the next one; fast-forwarding by hand is legitimate (idempotent with the script) and is the answer when the user wants it now. Never `--no-verify`, never force-push.
|
|
|
|
## Do not confuse with
|
|
|
|
- `omp-worktree-path-gotchas` — edits landing in the *wrong* worktree (cwd drift), not a stale main.
|
|
- `dotfiles-deployment-truth-audit` — classifies which files are tracked vs runtime state.
|
|
- `serverappconfigs-vault-page-registration` / `gitea-merge-form-encoded` — the PR mechanics upstream of this question.
|