Repo: recallnet/triggers (bare-storage + worktrees).
What happened: I ran mq land for a topic. mq committed the change onto the local protected main (8577b96) and attempted to publish, but the push was rejected as non-fast-forward because main had advanced on the remote to ce1ba47 ("fix(ui): simplify onboarding copy and align side buttons (#1)") via a GitHub PR merge — i.e. out-of-band, not through mq.
Result: local protected main (8577b96) and remote main (ce1ba47) diverged (both children of 9f80f33). mq doctor reports 'protected main has unpublished commits … run mq publish', but mq publish keeps failing non-fast-forward because mq has no upstream tracking and doesn't reconcile the out-of-band remote advance.
Expected: mq should detect the remote advanced, rebase/replay the queued protected commit onto the new remote tip (or fail loudly with a guided recovery), rather than leaving local protected main diverged with a commit that can never fast-forward.
Workaround used: reset local protected main to origin/main, then re-land the topic on top.
Ask: handle out-of-band remote advances on the protected branch (fetch+rebase protected, or a mq doctor --fix path that reconciles to the actual remote tip, not just the last mq-published sha).
Repo: recallnet/triggers (bare-storage + worktrees).
What happened: I ran
mq landfor a topic. mq committed the change onto the local protected main (8577b96) and attempted to publish, but the push was rejected as non-fast-forward because main had advanced on the remote to ce1ba47 ("fix(ui): simplify onboarding copy and align side buttons (#1)") via a GitHub PR merge — i.e. out-of-band, not through mq.Result: local protected main (8577b96) and remote main (ce1ba47) diverged (both children of 9f80f33).
mq doctorreports 'protected main has unpublished commits … run mq publish', butmq publishkeeps failing non-fast-forward because mq has no upstream tracking and doesn't reconcile the out-of-band remote advance.Expected: mq should detect the remote advanced, rebase/replay the queued protected commit onto the new remote tip (or fail loudly with a guided recovery), rather than leaving local protected main diverged with a commit that can never fast-forward.
Workaround used: reset local protected main to origin/main, then re-land the topic on top.
Ask: handle out-of-band remote advances on the protected branch (fetch+rebase protected, or a
mq doctor --fixpath that reconciles to the actual remote tip, not just the last mq-published sha).