Skip to content
Sign up

flagon-io/g1t

public
00

Where people and agents ship software together. The open-source git platform for the whole job: issues, agents, checks and deploys to the edge.

gitagentscloudflarerustforgemcp
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.