The #113 sweep rested on CLAUDE.md's premise that rtk either filters or passes through unchanged, so prefixing is always safe. Measured against rtk 0.42.4, that premise is false for several of the commands the sweep prefixed, and two skills were left giving wrong answers silently. Why: - `rtk git worktree list --porcelain -z` discards both flags and renders its own format. The `locked`/`lock_reason` fields git-worktrees Step 2 must emit are absent entirely, and paths under $HOME are abbreviated to `~/`. - `rtk git branch --list <name>` prints a phantom `* ` line even when nothing matches, so git-branches' stated ambiguity test — "output from both means the name is ambiguous" — reported every name as ambiguous. `tag --list` is a clean passthrough, so only one half broke. - `rtk git diff --name-only`/`--name-status` append a `Changes:` trailer to output documented as "one per line"; `--word-diff` emits none of the `[-removed-] {+added+}` markers its table describes; `rtk git log -L` truncates each line at ~72 chars, on the one command whose purpose is showing line content. - `rtk git stash pop` prints only `FAILED: git stash pop`, swallowing the conflict diagnostic and retained-entry message the surrounding prose tells the agent to rely on. Implementation notes: - Eleven sites reverted to bare `git`, each carrying its reason inline so the next sweep does not undo it. `mergetool` and `rebase -i` are reverted on clause 3's interactive limb only: the TTY defect does not reproduce — rtk filters exactly twelve subcommands and execs the rest — and ADR-0023 records that measurement rather than a convenient one. - ADR-0023 states the rule repo-wide with a third clause: a command whose output the skill parses, or which is interactive, stays bare. `plugins/git/README.md` is reduced to a pointer; its claim that gitea skills "contain no git/rtk mentions at all" was false, and its citation of `hard-rules.md` pointed at a file containing no occurrence of "rtk". - Eight gitea sites swept, all verified byte-identical passthroughs first. - `scripts/check-rtk-prefix.sh` gates clause 1. Run against main's pre-sweep corpus it reports 99 findings including every gitea site, so it would have caught the drift #113 was filed about. Impact: the gate covers clause 1 only, in shell-tagged fences and the opening span of Run cells. Clause 2 is not gateable — "Run `git switch`" and "`git switch` refuses" are the same tokens — and prose bullets are invisible to it. Both limits are recorded in gates.md rather than left implied. Refs: #113 ADR: 0023 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
3.8 KiB
topic, source_keys
| topic | source_keys | ||
|---|---|---|---|
| push |
|
Pushing
Default: safe push to the same-named branch on the remote.
- Force-push: never bare
--force. Usertk git push --force-with-lease --force-if-includes <remote> <branch>, after the SKILL.md Step 1 gate. - Basic:
rtk git push <remote> <branch> - Set upstream:
rtk git push -u <remote> <branch>— push and configure tracking - Multi-remote: push sequentially (
rtk git push origin develop,rtk git push staging develop), or add a second push URL withrtk git remote set-url --add <name> <url>to reach both in one command - Delete a remote branch:
rtk git push <remote> --delete <branch>— clearer than the:<branch>form - Bulk:
rtk git push --all(all local branches),rtk git push --tags(all tags),rtk git push origin <tag>(one tag) - Delete remote branches with no local counterpart:
rtk git push --prune origin 'refs/heads/*:refs/heads/*' - Force only part of a multi-ref push: prefix the one refspec that needs it with
+—rtk git push origin +release developforcesreleasewhile safe-pushingdevelop. A+prefix is a force-push and passes the SKILL.md Step 1 gate like any other.
Refspec syntax — [+]<src>[:<dst>]
| Pattern | Meaning |
|---|---|
<branch> |
Push to same-named remote branch |
<src>:<dst> |
Push <src> local ref to <dst> remote ref |
+<src>:<dst> |
Force this refspec (non-fast-forward allowed) — a force-push; passes the SKILL.md Step 1 gate |
:<branch> |
Delete remote <branch> |
refs/heads/*:refs/heads/* |
Glob: push all matching branches |
^refs/heads/dev-* |
Negative: exclude matching refs |
tag <name> |
Sugar for refs/tags/<name>:refs/tags/<name> |
Force-push safety — full detail
--force-with-lease rejects the push if the remote ref moved since your last fetch. Three forms:
| Form | What it protects |
|---|---|
--force-with-lease (bare) |
All refs being pushed, checked against your remote-tracking branch |
--force-with-lease=<refname> |
Named ref only |
--force-with-lease=<refname>:<sha> |
Named ref must be at exact SHA — most stable |
Caveat with the bare form: any background process that runs git fetch (IDE plugin, cron job, editor auto-fetch) updates your remote-tracking branch, which can make the lease check pass even though someone else pushed in between. The protection is silently defeated.
Two mitigations:
# Option 1 — dedicated push-only remote: background tools fetch `origin`, you push
# through a separate remote that nothing else touches, so its tracking ref can't be
# poisoned by an unrelated fetch.
# The inner `git config` is bare: its stdout becomes a remote URL, so any
# output rewriting would poison the remote silently.
rtk git remote add origin-push $(git config remote.origin.url) # inner bare per ADR-0023
rtk git push --force-with-lease origin-push
# Option 2 — explicit SHA via a local tag, unaffected by tracking-branch state
rtk git fetch
rtk git tag base master
git rebase -i master # bare, not `rtk` (ADR-0023): interactive sequence editor
rtk git push --force-with-lease=master:base master:master
--force-if-includes adds a second check on top of bare --force-with-lease: it verifies the remote-tracking tip actually appears in your local branch's reflog, i.e. you genuinely integrated it before rewriting. It is a no-op without --force-with-lease, and has no effect with the --force-with-lease=<ref>:<sha> form, which already pins an exact SHA.
Safest combination: rtk git push --force-with-lease --force-if-includes origin.
Server-side policy
receive.denyDeletes, receive.denyDeleteCurrent and receive.denyNonFastForwards are enforced on the remote regardless of any local flag — a hardened server rejects the push even with --force.