Skip to content
⌘K
Explore
Download
Docs
Sign in
Sign up
flagon-io
/
g1t
public
Star
0
Overview
Code
Issues
Pull requests
Workflows
Deployments
Insights
Files
Commits
Branches
Tags
Releases
Compare
c5c643bf3d593d1b7fe888f8205177787c0325a0
g1t
/
crates
Claude
agent
Merge remote-tracking branch 'origin/main' into claude/cool-newton-7nm8r9
c5c643b
2d ago
History
..
actions
blobstore
contracts
g1t
kit
rules
runner
scan
secrets
sshd
..
actions
A workflow's event payload (`github.event` and the file at `GITHUB_EVENT_PATH`) reads as GitHub's webhook payload does. Ids are whole numbers, the same for an object wherever it appears and safe in JavaScript: `repository.id`, `pull_request.id`, `issue.id`, `review.id`, `sender.id` and every user's and owner's `id`, with g1t's own id as `node_id`; `github.repository_id`, `github.repository_owner_id`, `github.actor_id` and their `GITHUB_*` variables are the same numbers. What g1t's API takes back by id (comments, releases, deployments, workflow runs) keeps g1t's id, so `github.event.comment.id` still edits the comment. A repository in a person's own workspace is owned by a `User`, not an `Organization`. A push says whether it was `forced`, `created` or `deleted`, and its `head_commit` is the commit pushed. A pull request's `base.sha` is the tip of the branch it merges into at the event, not the merge base, and `merge_commit_sha` is the commit it landed as once merged; pull requests and issues carry `node_id`, `assignee`, `locked`, dates and label and milestone ids, and a fork's head names the fork. `workflow_run` has the followed run's attempt, times, actor, head commit, workflow id and URLs. Tests compare each payload's keys and types with trimmed copies of GitHub's documented payloads, and the Actions guide says what differs. OIDC claims keep g1t's ids, so trust policies already written still match.
2d ago
blobstore
Merge branch 'worktree-agent-af58ac8933b0dd125'
6d ago
contracts
A pull request's `pull_request` runs build the pull request merged into its base branch, as on GitHub. g1t keeps `refs/pull/<number>/head` at every open pull request's head (a fork's or working copy's head commit is copied into the repository) and `refs/pull/<number>/merge` at a test merge commit of that head into the base branch's latest commit, moved whenever the head is pushed to, the pull request is opened or reopened, or its base changes; both can be fetched from the repository. A run's `github.sha` and `GITHUB_SHA` are that merge commit, `github.event.pull_request.merge_commit_sha` names it, `actions/checkout` fetches it as `+<sha>:refs/remotes/pull/<number>/merge` from the repository itself, and the workflow files and local reusable workflows are read from it; the run, its statuses and its check runs stay on the head, so required checks hold merges as before, and `pull_request_target` is unchanged. A pull request with conflicts starts no `pull_request` workflows, as on GitHub, and its checks box says why. g1t makes the merge without a sandbox, merging a file both sides changed line by line as git does; what it cannot merge itself (a rename on one side against a change on the other, more than 300 changed files) builds the head as before. The Actions and Checks guides say so.
2d ago
g1t
g1t push: images with layers of any size, uploaded in chunks under the edge's limit
1w ago
kit
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.
4d ago
rules
Merge checks: statuses and check runs on every commit
5d ago
runner
`actions/checkout` is the real action now, at the version a step names: g1t's runner no longer checks out in its place. It fetches from g1t with the job's token, as on GitHub, including a pull request's test merge commit, which g1t now keeps in the repository as `refs/pull/<number>/merge` beside `refs/pull/<number>/head`, and its post step removes the credential it left. Every input and output is the action's own. In a job container whose image has no git, the action falls back to a tarball download g1t does not serve yet, and `lfs` finds no files: the limitations say so, with what to do instead.
2d ago
scan
A push is checked once and side by side: its pack is read and its bases fetched once for the rules, the workflow gate and the secret scan, which run together, other services are asked while the pack is read, and cache writes and rule records finish after git has its answer
4d ago
secrets
Mission control shows where you are needed and what agents landed without you; git answers in about 200ms
1w ago
sshd
The docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.
4d ago