git-pull-rebase-trap

This card ships three parts: an explanation of the trap, prevention-by-recipe for adopter-owned enforcement, and the recovery runbook below. It deliberately ships no executable hook. Enforcement that must fire belongs in the adopter's environment; the card remains the model-invocable reference.

The trap

git pull --no-ff does not override pull.rebase=true. The --no-ff flag applies to merge operations; when the effective pull strategy is rebase, --no-ff is silently ignored and the rebase proceeds anyway.

When local has diverged from origin (e.g., 22 local commits + N remote commits), this rewrites every local commit with a new SHA. Any artifact that referenced the old SHAs — state files, gate-event ledgers, retrospection logs, release notes — is now stale and must be backfilled.

When this fires

Any of these conditions:

• git config pull.rebase returns true (globally or per-repo)
• git config branch.<current>.rebase is true
• A [pull] rebase = true block exists in .git/config or ~/.gitconfig

The trap fires whether you pass --no-ff or no flag at all: the configured pull strategy is rebase, so a merge-side flag is simply ignored and your commits are rebased. --ff-only is the exception — on diverged history it refuses outright (git aborts with a "cannot fast-forward" message; the exact wording varies by git version) instead of silently rebasing. That makes --ff-only a loud guard rail rather than a silent SHA rewrite — but not a usable everyday pull, since it also refuses every legitimate diverged sync.