Claudeagent and ClaudeagentA 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.5dee456History
- ..
- access.test.ts
- access.ts
- cloudflare.ts
- custom-hostnames.ts
- domains.ts
- environments.test.ts
- environments.ts
- hostname.test.ts
- hostname.ts
- index.ts
- metering.test.ts
- metering.ts
- moves.flow.test.ts
- moves.test.ts
- moves.ts
- names.test.ts
- names.ts
- redirect.test.ts
- redirect.ts
- repo-deployments.ts
- retries.test.ts
- retries.ts
- workflow-builds.flow.test.ts
- workflow-builds.test.ts
- workflow-builds.ts