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
- ..
- invites
- access.rs
- account_deletion.rs
- admin.rs
- aliases.rs
- avatars.rs
- crypto.rs
- deletion.rs
- deploy_keys.rs
- device.rs
- directory.rs
- dock.rs
- email.rs
- emails.rs
- github.rs
- invites.rs
- job_tokens.rs
- lib.rs
- members.rs
- oauth.rs
- paid.rs
- people.rs
- profiles.rs
- rename.rs
- run_credentials.rs
- security.rs
- shared_invites.rs
- sounds.rs
- teams.rs
- throttle.rs
- token_reach.rs
- tokens.rs
- two_factor.rs
- workspaces.rs