syntaqxThe audit log records a push refused at git's first request, tells deploy keys from workspace tokens, and the activity digest names a workspace as itself. git asks for the refs it may push to (GET info/refs?service=git-receive-pack) before it sends a pack, and that is where a credential that does not reach the repository or may not push is refused, so such a push left no entry: only the pack's POST was recorded. Repos now starts an entry for that first request too and records it only when it is refused (any 4xx or 5xx), as a denied git.push with the refusal's own message, so an allowed push is still one entry. A push allowed through is recorded under the rule for what pushed: person, workspace-token, deploy-key (new; a deploy key resolves as its workspace, and was recorded as workspace-token) or agent-token; the audit page labels deploy-key. The digest counted any wsp_ actor as g1t's agent (user:usr_g1t_agent), so a workspace token's pushes and changes were g1t's; it now keeps them the workspace's (user:wsp_<id>), which the site already never counts among the people. The audit log guide says what a refused push records, who the actor is and which rules a push carries. Checked: cargo test -p g1t-repos --lib (317, new: a workspace token's push is the workspace's with its token id and no person, a deploy key has its own rule, a push and one refused at its first request are recorded and an allowed first request is not, fetches are not), cargo test -p g1t-events --lib (55) and wasm32 checks of both; the site's audit and home tests (27) and typecheck; the docs build.bd8913dHistory
- ..
- coordination
- authored.rs
- checks.rs
- codeowners.rs
- commit_checks.rs
- contributions.rs
- decisions.rs
- ghost.rs
- guardrails.rs
- inbox.rs
- insights.rs
- insights.sql
- integration.rs
- labels.rs
- lib.rs
- lifecycle.rs
- mergeability.rs
- milestones.rs
- prefetch.rs
- queue.rs
- queue_tests.rs
- retired.rs
- reviews.rs
- rows.rs
- rulesets.rs
- runs.rs
- settings.rs
- statuses.rs
- team_reviews.rs