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
- ..
- folios
- kinds
- access.test.ts
- access.ts
- blocks.ts
- chunks.test.ts
- chunks.ts
- citations.test.ts
- citations.ts
- diff.test.ts
- diff.ts
- edits.test.ts
- edits.ts
- events.ts
- files.test.ts
- files.ts
- folio-access.test.ts
- index.ts
- indexer.test.ts
- indexer.ts
- markdown.test.ts
- markdown.ts
- persist.ts
- recall.test.ts
- recall.ts
- repo-docs.test.ts
- repo-docs.ts
- repo-spaces.ts
- room.ts
- search.test.ts
- search.ts
- sigv4.test.ts
- sigv4.ts
- slugs.test.ts
- slugs.ts
- staleness.ts
- templates.ts
- threads.test.ts
- threads.ts
- tree.test.ts
- tree.ts
- vectors.ts
- who.ts