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
- ..
- accounts.rs
- ai.rs
- attribution.rs
- budget.rs
- cards.rs
- catalogue.rs
- catalogue_tests.rs
- charged.rs
- closing.rs
- compute.rs
- costs.rs
- credits.rs
- cycle.rs
- details.rs
- features.rs
- gateway.rs
- gateway_tests.rs
- grants.rs
- invoices.rs
- keeper.rs
- lib.rs
- limits.rs
- margin.rs
- overages.rs
- platform.rs
- pricing.rs
- rename.rs
- report.rs
- requests.rs
- reset.rs
- retention.rs
- sales.rs
- statement.rs
- storage.rs
- stripe.rs
- stripe_sync.rs
- subscriptions.rs
- tax.rs
- tokens.rs
- webhooks.rs