让 7 号机当合并员：三台开发机的代理 PR 怎么一个个安全进主干（中英切换）

Same three-person team, same seven computers. Agents on machines 1, 2 and 3 branch off main and work; machines 4 and 5 review; machine 6 does Windows validation; machine 7 has never had a fixed job.

Tuesday afternoon, all three dev machines open PRs at about the same time. Machine 1 does a refactor: it renames calc_total to order_total, adds a tax-rate parameter, and updates every call site in the repo. Machine 2 adds an export command that calls calc_total, because that is what the function was called on main when it branched. Machine 3 adds a discount command and, like machine 2, appends one line to the command registry and one to the CHANGELOG. All three PRs have green CI, and the review machines pass all three. On GitHub, each one shows MERGEABLE / CLEAN with a green merge button.

Merge machine 1's PR first: main stays green. Merge machine 2's: no conflict, and main goes red: ImportError: cannot import name 'calc_total', so the whole test module fails to import. Machine 3's PR now has conflicts in CHANGELOG.md and shop/registry.py, the two files where everyone appends a line at the end.

I didn't make this scenario up. As you'll see below, I ran it with three real PRs in a real GitHub repository. My claim: once three machines ship PRs in parallel, "whoever finishes review clicks merge" stops working. One machine should do the merging. It takes PRs one at a time, runs the tests on "current main plus this PR", and bounces anything that fails back to the dev machine. Machine 7, which has been sitting idle, gets that job. You also need to restructure the few files where everyone appends a line at the end. If you don't, the merge clerk will spend most of its time bouncing conflicts.

There are four experiments below: a simulation in local git repos, the merge train running on real GitHub PRs, a pairwise dry merge of the 60 PRs currently open in a busy open-source repo, and a comparison of common ways to avoid conflicts. All scripts are inline, and the bundle is linked at the end.

Why every PR was green and main still went red

Start with what CI actually tested. A GitHub Actions pull_request run checks out refs/pull/N/merge: the PR merged with main as it was when the run was triggered (docs). So a green check means "fine combined with main from ten minutes ago." It has never seen anything that merged after that.

MERGEABLE on the PR page means only one thing: git's three-way merge found no textual conflict. Nothing gets compiled and no tests run. Machine 1 changed pricing.py and total.py, and machine 2 added export.py. No line was touched by both, so git says the merge is clean. But machine 2's new from shop.pricing import calc_total depends on a name machine 1 just deleted. That is a semantic conflict: the text merges and the meaning doesn't. The only way to find one is to run the tests on the merged tree.

Human teams hit this too, just rarely. One person opens a PR or two a day, the PRs are spread out, and people roughly know what everyone else is touching. Agents push three things to the extreme at once. Parallelism: three machines branch from the same main commit and work blind to each other. Breadth: an agent doing a refactor updates every call site in the repo in one go, and an agent adding a feature also updates the registry, the CHANGELOG, the dependency manifest and the docs index while it's there. Bunching: agents are fast, so PRs arrive in clumps within an hour, and the review machines release them in clumps too. Three PRs start from the same commit and merge within the same hour, and none of their CI runs ever saw the others.

Experiment 1: a local simulation, merged the default way

I first reproduced the scenario in a local git repo: a tiny Python order CLI with three branches, one per dev machine. The merge step mimics GitHub's squash merge. Each PR runs its tests on its own branch, then gets squashed onto whatever main is at that moment, and nothing is re-tested afterwards. That is exactly what a repo without branch protection does every day. Raw output:

== PR m1/rename-total: CI on its own branch
3 passed in 0.01s
== squash-merge m1/rename-total onto main ab1c305
   merged clean -> 6a8135e
== tests on main after merging m1/rename-total
3 passed in 0.01s
== PR m2/export-cmd: CI on its own branch
3 passed in 0.01s
== squash-merge m2/export-cmd onto main 6a8135e
   merged clean -> 862b94c
== tests on main after merging m2/export-cmd
E   ImportError: cannot import name 'calc_total' from 'shop.pricing'
== PR m3/discount-cmd: CI on its own branch
3 passed in 0.01s
== squash-merge m3/discount-cmd onto main 862b94c
   CONFLICT (content): Merge conflict in CHANGELOG.md
   CONFLICT (content): Merge conflict in shop/registry.py

Both kinds of failure showed up. The semantic conflict turns main red, and it does so quietly: the merge button was green, and nobody runs the tests right after merging. The textual conflict is louder but easier to handle, since at least it stops you. The first kind is the expensive one. Every agent that branches from a red main starts on a broken base, so the next PRs from machines 1, 2 and 3 start failing tests for no visible reason, and the agents try to "fix" breakage they didn't cause.

Experiment 2: how many PRs conflict with each other in a real repo right now

A local simulation shows the mechanism, not how often it happens. I took a repo with a lot of PR traffic, anomalyco/opencode. At 18:45 Taipei time on 2026-10-22 I fetched its 60 newest open PRs and dry-merged every pair with git merge-tree. That command needs no checkout: it computes the merge inside the object store and exits non-zero on a conflict.

Of the 60 PRs, 14 already conflicted with main, so their authors have to rebase first. The other 46 could each merge cleanly right now, but 12 pairs among them conflict: as soon as one PR in a pair lands, the other one becomes a conflict. Ten of those 12 pairs are on a single file, packages/web/src/content/docs/ecosystem.mdx. I opened it: it's a Markdown table of community plugins, and every PR appends a row at the bottom. According to the GitHub API, the other files being modified by three or more open PRs at once are bun.lock, i18n/en.ts and package.json. They're all the same kind of file: registries, lockfiles and string tables that everyone has to add something to.

This is a community project and its PRs aren't necessarily written by agents, so don't apply these numbers directly to your team. What they show is where conflicts land. At least in this repo, conflicting PRs rarely collide in complicated business logic; almost all of them collide on one or two shared-list files. For a team with three dev machines that's good news, because a handful of files can be fixed once.

Why not just use GitHub's merge queue

GitHub already has a feature for this, called merge queue. A queued PR is combined with the PRs ahead of it on a temporary branch, the required checks run there, and the PR merges only if they pass. It works on the same principle as the setup in this post. The question is whether you can turn it on. According to the docs, it's available only on public repos owned by an organization and on private repos of organizations on Enterprise Cloud. Plenty of three-to-five-person teams keep a private repo under someone's personal account. My own repo can't even read the rulesets API:

$ gh api repos/shuizhengqi1/pages/rulesets
gh: Upgrade to GitHub Pro or make this repository public to enable this feature. (HTTP 403)

A step down from that, branch protection has a "require branches to be up to date before merging" setting. It does stop semantic conflicts, because every PR has to rebase onto the latest main and re-run CI before it can merge. But it causes rebase storms: each merge makes every other waiting PR stale, so they all have to rebase and re-run CI again. Say six PRs pass review at once. Landing all of them takes 6+5+4+3+2+1 = 21 CI runs; testing them one at a time in a queue takes 6. That's arithmetic, not a measurement, but the logic is simple. Worse, the rebases usually fall to the agents on the dev machines. Each one eats into the agent's context, and the agent may "improve" a few lines while it's at it.

So for a private repo under a personal account, the practical move is to build a minimal merge queue yourself. It never touches the PR branches and never asks an agent to rebase. It just builds "main + PR" as a candidate commit on the clerk's own machine and tests that.

The setup: machine 7 as the merge clerk

The core is a script that never touches a working tree. It uses git merge-tree --write-tree (git 2.38+) to compute the tree that a squash merge of the PR onto main would produce, wraps that tree in a candidate commit with git commit-tree, checks the commit out into a temporary worktree, and runs the tests there. It exits 10 on a conflict and 20 if the tests fail; on success it prints the candidate commit and tree hashes:

train-step.sh

#!/usr/bin/env bash
# train-step.sh <base-ref> <head-ref>
# Test what main WOULD look like after squash-merging <head-ref>, without touching
# any checkout. Needs git >= 2.38 (merge-tree --write-tree).
#   exit 0  -> prints "<candidate-commit> <tree>"; tests passed on the combination
#   exit 10 -> textual conflict; prints the conflicted paths
#   exit 20 -> merges clean but TEST_CMD fails on the combination; log in $TRAIN_LOG
set -uo pipefail
base=$(git rev-parse "$1") head=$(git rev-parse "$2")
TEST_CMD=${TEST_CMD:-"python3 -m pytest -q"}
TRAIN_LOG=${TRAIN_LOG:-$(mktemp)}

if ! out=$(git merge-tree --write-tree --name-only --no-messages "$base" "$head"); then
  echo "$out" | tail -n +2        # line 1 is the (conflicted) tree id
  exit 10
fi
tree=$(echo "$out" | head -1)
cand=$(git commit-tree "$tree" -p "$base" -m "train candidate: $2")

wt=$(mktemp -d)
git worktree add -q --detach "$wt" "$cand"
( cd "$wt" && eval "$TEST_CMD" ) >"$TRAIN_LOG" 2>&1; rc=$?
git worktree remove --force "$wt"
[ $rc -eq 0 ] || exit 20
echo "$cand $tree"

A wrapper runs it on every GitHub PR labelled queue. The review machines can add that label when they approve, which plugs into the label flow from the post two days ago. The clerk does four things. It takes the queue in PR-number order. On a conflict or a red test run, it removes queue, adds train:conflict or train:red, and posts the conflicting files or the test output as a comment. On green, it merges with gh pr merge --squash --match-head-commit, which guarantees that the commit it tested is the commit that merges; if the dev machine pushed something in the meantime, the merge is refused. After merging, it checks that main's tree matches the tree it tested. If the same PR gets bounced three times, the clerk labels it train:human and stops the agent-vs-clerk ping-pong.

merge-train.sh

#!/usr/bin/env bash
# merge-train.sh — run on machine 7 inside a clone of the repo. Merges PRs labelled
# `queue` one at a time, each tested on top of the CURRENT base branch.
# Works on a personal private repo (no merge queue, no branch protection needed).
#   BASE=main TEST_CMD="npm test" ./merge-train.sh          # one pass
#   while sleep 120; do ./merge-train.sh; done              # machine 7 loop
set -uo pipefail
BASE=${BASE:-main}
MAX_BOUNCES=${MAX_BOUNCES:-3}
export TEST_CMD=${TEST_CMD:-"python3 -m pytest -q"}
STEP="$(cd "$(dirname "$0")" && pwd)/train-step.sh"
MARK='<!-- merge-train -->'

bounce() {  # bounce <pr> <label> <message-file>
  local pr=$1 label=$2 msg=$3 n
  n=$(gh pr view "$pr" --json comments --jq "[.comments[].body|select(contains(\"$MARK\"))]|length")
  if [ "$n" -ge "$MAX_BOUNCES" ]; then label=train:human; fi   # stop the agent ping-pong
  gh pr edit "$pr" --remove-label queue --add-label "$label" >/dev/null
  { echo "$MARK"; cat "$msg"; } | gh pr comment "$pr" --body-file - >/dev/null
  echo "BOUNCED #$pr -> $label"
}

for pr in $(gh pr list --base "$BASE" --label queue --state open --json number --jq 'sort_by(.number)|.[].number'); do
  git fetch -q origin "$BASE" "+refs/pull/$pr/head:refs/train/pr-$pr" || continue
  base_sha=$(git rev-parse "origin/$BASE"); head_sha=$(git rev-parse "refs/train/pr-$pr")
  export TRAIN_LOG=$(mktemp); msg=$(mktemp)
  res=$("$STEP" "$base_sha" "$head_sha"); rc=$?
  case $rc in
  10) { echo "**Conflicts with \`$BASE\` @ ${base_sha:0:7}** in:"; echo "$res" | sed 's/^/- `/; s/$/`/'
        echo; echo "Rebase on \`$BASE\`, keep both sides' intent, push; then re-add \`queue\`."; } >"$msg"
      bounce "$pr" train:conflict "$msg"; continue;;
  20) { echo "**Green on its own branch, red on top of \`$BASE\` @ ${base_sha:0:7}.** Tail of \`$TEST_CMD\`:"
        echo '```'; tail -n 25 "$TRAIN_LOG"; echo '```'
        echo "Something merged since you branched changes what this PR relies on. Fix on top of \`$BASE\`, then re-add \`queue\`."; } >"$msg"
      bounce "$pr" train:red "$msg"; continue;;
  0)  tested_tree=${res#* };;
  *)  echo "train-step failed for #$pr (rc=$rc)"; continue;;
  esac

  # Compare-and-swap: only merge if nobody moved BASE or pushed to the PR meanwhile.
  [ "$(git ls-remote origin "refs/heads/$BASE" | cut -f1)" = "$base_sha" ] || { echo "#$pr: $BASE moved, retry next pass"; continue; }
  if ! gh pr merge "$pr" --squash --match-head-commit "$head_sha" >/dev/null; then
    echo "#$pr: merge refused (new push?), retry next pass"; continue
  fi
  git fetch -q origin "$BASE"
  merged_tree=$(git rev-parse "origin/$BASE^{tree}")
  if [ "$merged_tree" = "$tested_tree" ]; then echo "MERGED  #$pr  tree ${tested_tree:0:7} == tested"
  else echo "WARNING #$pr: $BASE tree ${merged_tree:0:7} != tested ${tested_tree:0:7} (someone merged by hand?)"; fi
done

In my own repo I used a throwaway branch as "main", pushed the same three branches as in experiment 1, opened three real PRs (#30, #31, #32), labelled them queue, and ran the script from the box. Before the run, GitHub showed all three as MERGEABLE / CLEAN.

The first run broke, and the bug was in my own script. #30 merged fine, then the script died when it reached #31:

MERGED  #30  tree 97e866c == tested
../../kit/merge-train.sh: line 31: TEST_CMD: unbound variable

The red-test branch writes TEST_CMD into its comment, but I had only given that variable a default inside train-step.sh. With set -u on, the undefined variable killed the script. #31 kept its queue label without being bounced, and nothing after it was processed. Because the script is idempotent, adding the default and re-running picked up where it stopped. The lesson: before the clerk goes live, deliberately feed it a PR that will go red, and walk the bounce path for real. If you've only tested the happy path, you haven't tested the clerk. The second run, after the fix:

BOUNCED #31 -> train:red
MERGED  #32  tree 7c0afb6 == tested

Here's how the comment on #31 starts. The full test output is pasted in as well, so machine 2's agent knows exactly where to look:

**Green on its own branch, red on top of `lab/train-2026-10-22` @ 6640300.**
...
shop/commands/export.py:2: in <module>
    from shop.pricing import calc_total
E   ImportError: cannot import name 'calc_total' from 'shop.pricing'

Next I played machine 2's agent fixing the PR. I rebased onto the new main, where #32 had already landed, so CHANGELOG.md and registry.py conflicted; I kept both sides' lines. I switched calc_total to order_total, ran the tests locally, and force-pushed. Before pushing, I tried merging with the old head SHA to confirm --match-head-commit really blocks it:

$ gh pr merge 31 --squash --match-head-commit 732bdaa...
GraphQL: Head branch was modified. Review and try the merge again. (mergePullRequest)

Then I re-added queue and hit another small snag. Running the clerk right after adding the label, gh pr list --label queue came back empty; a few seconds later #31 showed up. So run the clerk in a loop every minute or two, and don't count on it reacting the instant a label is added. Third run:

MERGED  #31  tree b4a7ff9 == tested

All three PRs landed. After every merge, main's tree was identical to the tree the clerk had tested, and the final main reported 3 passed. The two-PR pass (one bounce, one merge) took 29 seconds in total. The tests themselves took 0.06 seconds; almost all the rest was gh round trips to the GitHub API. To estimate throughput, budget a fixed cost of roughly ten-plus seconds per PR plus the length of your own test suite.

One more result. In a local run I changed the merge order to 2, 3, 1, and this time the PR that got bounced was machine 1's refactor:

MERGED   m2/export-cmd -> main 263132a
BOUNCED  m3/discount-cmd: conflict in CHANGELOG.md shop/registry.py
BOUNCED  m1/rename-total: green alone, red on main 263132a:

All the clerk can tell is who arrived later and no longer fits on main. It can't tell whose fault the break is. That matters a lot in practice: a destructive refactor such as a rename or a function deletion that lands late in the queue gets bounced by feature PRs again and again, and each time it has to rescan the whole repo for call sites. The fix isn't in the clerk; it's in how you make the change, which the next section covers.

Removing conflicts at the source

The clerk keeps main green, but it's a backstop: it doesn't reduce the number of conflicts. Every bounce costs the dev machine another round of work. I compared several common approaches locally:

A common suggestion is to set merge=union on these files in .gitattributes, which makes git keep both sides' lines instead of reporting a conflict. For a CHANGELOG, where every line stands alone and order doesn't matter, it works. When I applied it to the Python registry, git reported no conflict and produced this:

from shop.commands import total, export

COMMANDS = {
    "total": total.run,
    "export": export.run,
from shop.commands import total, discount

COMMANDS = {
    "total": total.run,
    "discount": discount.run,
}

The tests failed with SyntaxError: '{' was never closed. A JSON list fared no better: each side added one entry, and the union result was missing a comma between them, so json.tool reported Expecting ',' delimiter. Union turns a loud problem into a silent one, which is worse than a conflict. My advice: use merge=union only on plain-text lists, and never on a file that has syntax.

What actually works is three structural changes.

First, split the CHANGELOG into fragments. Each PR creates changes/<branch>.md, and the release script concatenates them. Two PRs that create two different files can't conflict.

Second, make the registry self-registering. Each command module declares its own NAME, and the registry scans the directory with pkgutil.iter_modules to collect them. Adding a command means adding a file, not editing a shared dict. The same idea works for routes, plugin lists, feature flags and docs indexes. If opencode's plugin table were one file per plugin, 10 of those 12 conflicting pairs would never happen.

Third, do renames as expand/contract. Machine 1's PR adds order_total and keeps calc_total as a one-line forwarding alias. Once git grep calc_total finds no other callers on main, a small follow-up PR removes the alias. Code machine 2 wrote against the old name keeps working, and the refactor PR stops getting bounced just because it reached the queue late.

With all three changes in place, I re-ran the same three PRs with the same default merge. All three landed cleanly, main reported 3 passed after each merge, and the registry picked up discount, export and total automatically. Note that no clerk was involved this time: the conflicts disappeared at the source instead of being caught.

Conflict radar: warn the dev machines early

One more cheap early warning: dry-merge every pair of open PRs with git merge-tree and tell the affected dev machines about any conflict before it bites. The opencode numbers above came from this script.

conflict-radar.sh

#!/usr/bin/env bash
# conflict-radar.sh — which open PRs will conflict with each other once one merges?
# Dry-runs every pair with `git merge-tree` (no checkout, ~ms per pair).
#   ./conflict-radar.sh --gh [BASE]        # all open PRs of the current GitHub repo
#   ./conflict-radar.sh ref1 ref2 ...      # local branches
set -uo pipefail
if [ "${1:-}" = --gh ]; then
  BASE=${2:-main}; refs=()
  for pr in $(gh pr list --base "$BASE" --state open --json number --jq '.[].number'); do
    git fetch -q origin "+refs/pull/$pr/head:refs/radar/$pr" && refs+=("refs/radar/$pr")
  done
else refs=("$@"); fi
for ((i = 0; i < ${#refs[@]}; i++)); do
  for ((j = i + 1; j < ${#refs[@]}; j++)); do
    a=${refs[i]} b=${refs[j]}
    if ! out=$(git merge-tree --write-tree --name-only --no-messages "$a" "$b" 2>/dev/null); then
      echo "CONFLICT  ${a##*/} x ${b##*/}: $(echo "$out" | tail -n +2 | sort -u | tr '\n' ' ')"
    fi
  done
done

On the three local branches it reports export-cmd x discount-cmd: CHANGELOG.md shop/registry.py. It does not report the machine 1 / machine 2 pair, because that pair has no textual conflict, only a semantic one. So the radar is a warning, not a gate. The gate is still the clerk.

It isn't free either. Sixty PRs make 1,770 pairs, which took 7 minutes 26 seconds on a --filter=blob:none partial clone, mostly spent downloading objects on demand. Your own repo has a full local object store and far fewer PRs, so the cost there is negligible.

Rules for the dev machines' agents

None of this sticks unless it goes into the rules file the agents read every day; otherwise they'll append to the registry again next time. This is what I put in AGENTS.md:

AGENTS.parallel.md

## Parallel PR rules (dev machines 1-3)

- One PR = one intent. Do not bundle a rename/move/delete of shared code with feature work.
- Renaming or removing anything other files use: expand/contract. PR 1 adds the new name
  and keeps the old one as a thin alias; a later PR removes the alias once
  `git grep <old-name>` is empty on main.
- Never append to a shared list by hand. Changelog: create `changes/<branch>.md`.
  Commands/routes/plugins: add a new module that declares itself; registries discover.
- Lockfiles: only a PR whose task is "change dependencies" may touch them. If you need a
  new dependency for a feature, open that dependency PR first and stop.
- Before opening a PR, run `kit/conflict-radar.sh --gh main` and list any PR you conflict
  with in your PR description.
- Do not merge. Machine 7 merges PRs labelled `queue`. If it bounces your PR
  (`train:conflict` / `train:red`), rebase on main, fix, push, re-add `queue`.
  After `train:human`, stop and wait for a person.

The lockfile rule deserves its own note. When bun.lock or package-lock.json conflicts, you can't merge it by hand; you can only regenerate it. If two PRs each add a dependency, the regenerated lockfile matches neither side. The simplest rule: dependency changes go in their own PR, ahead of the feature PRs that need them.

Costs, and when this doesn't fit

The clerk is serial. Each PR costs roughly its test time plus ten-plus seconds of API overhead. For three people shipping twenty or thirty PRs a day with a test suite under five minutes, one machine 7 is plenty. If your tests take twenty minutes or more and PRs are plentiful, the queue will keep growing. At that point, test two PRs together and merge both if they pass, splitting them apart only on failure. Or move the repo into an organization, make it public, and use GitHub's merge queue, which can pre-build several combinations in parallel.

It's only as good as your tests. The clerk can only catch what the tests catch. If one PR changes the shape of a config file and another reads the old shape along a path no test covers, the clerk lets them through. The same goes for the machine 6 Windows gate from the previous post: if it must pass, the clerk should also check that the PR's gate check is green before merging.

A private personal repo can't enforce any of this. Without branch protection, anyone can still click the merge button. After each merge the clerk compares main's tree with the tree it tested and prints a WARNING if they differ, but that's an alert after the fact. Real enforcement requires a plan upgrade or moving the repo into an organization. Until then, it rests on a team agreement plus that after-the-fact alert.

Machine 7 is a single point of failure. If it's off, merging stops. That failure is safe: main can't break because of it, the PRs just pile up. For an emergency merge, run train-step.sh by hand on any machine and click merge if it passes.

If you have one dev machine, or two or three PRs a day, skip all this. In that situation, rebasing locally and running the tests before you merge is enough. The clerk solves a problem that comes from parallelism; without parallelism you don't have the problem.

Five things to do tomorrow

1. Run conflict-radar.sh --gh main on your repo, and count the most-changed files over the last hundred commits with git log --name-only. The top of that list is usually registries, CHANGELOGs and lockfiles.
2. Take the file with the most conflicts and convert it to fragments or self-registration. That's usually half a day of work, and it removes more conflicts than anything else.
3. Clone the repo on machine 7, create the four labels (queue, train:conflict, train:red, train:human), and do one manual run of BASE=main TEST_CMD="your CI test command" ./merge-train.sh.
4. Deliberately open a PR that is green alone and red when combined, and confirm the clerk bounces it with the test output in the comment. That's exactly where my own first run fell over.
5. Paste AGENTS.parallel.md into your agents' rules file, and tell the three people on the team that from today nobody clicks merge by hand.

Scripts, rules and all the experiment scripts are bundled here: merge-train-kit.tar.gz.

What I actually ran, and what I didn't

One note first: the three "agent" changes are branches I wrote by hand to mimic how agents typically make such changes; no agent generated them live. What's under test is the merge step, and who wrote the diffs doesn't change the result.

Run on real GitHub: merge-train.sh handled three real PRs (#30–#32) on throwaway branches in shuizhengqi1/pages. That covered the red-test bounce and its comment, --match-head-commit refusing a stale SHA, re-queue and merge, and the tree-hash check after each merge. Afterwards I deleted the throwaway branches and the four labels; the three PRs remain in the repo as merged records. The conflict bounce (train:conflict) ran only locally. On GitHub it goes through the same bounce function, but I didn't trigger it there specifically.

Run locally: the default-merge vs. merge-train comparison, the reordered run that bounced the refactor, merge=union on a CHANGELOG, a Python registry and a JSON list, the fixed layout with fragments + self-registration + alias, and the conflict radar. The opencode data comes from a read-only fetch of the PRs open at that moment plus local dry merges.

Not run: ci-merge-group.yml is for repos that can use GitHub's merge queue; I don't have one, so it's untested. Batching two PRs at a time is only an idea and isn't implemented in the script. The 21 vs. 6 rebase-storm figures are calculated, not measured.