| 1 | # 0039 — A pull request's commits are recorded in its timeline as each push lands |
| 2 | |
| 3 | **Status:** adopted |
| 4 | |
| 5 | ## Decision |
| 6 | |
| 7 | Opening a pull request, and every later push that moves its head, writes `issue_event` rows: one `committed` row per commit the push added, and a |
| 8 | |
| 9 | A push added the commits its new head reaches that neither its old head nor the base branch does. Base commits pulled in by merging or rebasing onto the base never show, matching the request's own commit list. |
| 10 | |
| 11 | `PullRequestPushesService.recordPush` is the one place this happens, and every writer of a branch calls it after the push lands: git pushes over HTTP and SSH, applied suggestions, and merges into a branch another request is from. Imports call it for none of their pushes. |
| 12 | |
| 13 | A `committed` row keeps the commit's subject and author name, so it still reads after a force push leaves the commit unreachable. |
| 14 | |
| 15 | The same transaction publishes `pull_request.synchronized`, carrying `before`, ` |
| 16 | |
| 17 | ## Why |
| 18 | |
| 19 | Reading commits from git when the timeline loads would place them by commit date, which the author's machine sets and a rebase rewrites, and a force push would erase the old commits without a trace. Rows record when each push actually happened and who made it. |
| 20 | |
| 21 | ## Consequences |
| 22 | |
| 23 | - Requests opened before this change show no commits for what was pushed before it. |
| 24 | - One push adds at most 250 commits to a timeline, the newest ones. |
| 25 | - A push that lands while the API cannot write the rows, or that crashes between the two, leaves its commits out. Nothing reconciles them. |
| 26 | - The commit's author is shown as git recorded the name, not linked to an account. |