Repository navigation
A merge is a shape, not a sentence — and the queue would cost more, not less - #3189
Merged
Merged
Conversation
…3134) tri pr-cost counted update-branch merges by SUBJECT PREFIX. The loop then began passing its own -m "Merge origin/master into <branch>", matching none of the three prefixes, so the command printed "update-branch merges 0" and "cost of the rule 0 minutes" -- pricing the up-to-date rule as free while it was charging. Nothing moved but my own commit-message habit. Measured on four PRs: by prefix 0/0/4/0, by parent count 1/1/4/3. It agreed only on the one PR that used git's default message and missed another session's #3178 entirely. A merge commit has two parents; the prefix list is gone rather than widened, because a longer list of spellings is the same defect with more rope. Same window: content 18 -> 12, merges 0 -> 6, cost 0 -> 176 minutes. Over 20 PRs: 43 commits, 15 merges, 307 minutes. And the corrected number argues AGAINST the merge queue #3134 proposes. Every pull_request commit fires 23 workflow runs (median over 200 recent runs grouped by head_sha and event; min 20, max 23), so in runs: today 43 commits x 23 = 989 queued 28 content x 23 + 20 builds x 23 = 1104 (+115, +12%) A queue charges one build per PR whether or not it ever caught up, and 10 of 20 merged with ZERO catch-ups. Average 0.75; break-even batch 1.33; only one loop/ PR is open at a time, so batching is ~1. The cause is a fix already merged here: #3166's narrow rule drove the average below the queue's break-even. The remedy #3134 proposes was made unprofitable by a remedy already shipped, and nothing noticed because the two were never priced in the same unit. pr-cost now prints that arithmetic itself, and states what it does not establish: a queue wins at batch >= 1.33, which is about arrival rate, and it does nothing for the waiting that --required-only already removes. SKILL.md 530-531. Posted to #3134. Refs #3134 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The tool priced the up-to-date rule at zero, and its author broke it
tri pr-costcounted update-branch merges by subject prefix —Merge branch 'master',Merge remote-tracking,Merge branch "master". The loop then began passing its own-m "Merge origin/master into <branch>", which matches none of them:It priced the rule as free while the rule was charging. Measured on four pull requests — by prefix 0 / 0 / 4 / 0, by parent count 1 / 1 / 4 / 3. It agreed only on the one PR that happened to use git's default message, and missed another session's #3178 entirely.
A merge commit has two parents. Structural, immune to wording, unbreakable by anyone choosing a nicer
-m. The prefix list is gone rather than widened — a longer list of spellings is the same defect with more rope.Over 20 merged PRs: 43 commits, 15 merges, 307 minutes.
Nothing moved but my own habit. When a matcher reads a human-chosen string, its population is a habit — and habits change without a commit to blame.
And the corrected number argues against #3134, not for it
Every
pull_requestcommit here fires 23 workflow runs (median over 200 recent runs grouped byhead_shaand event; min 20, max 23). In the unit a queue is made of:A merge queue charges one build per pull request whether or not it ever had to catch up — and 10 of 20 (50%) merged with zero catch-ups. Average catch-ups per PR 0.75; break-even batch size 1.33 PRs per build; only one
loop/PR is open at a time, so batching is ~1.The cause is a fix already merged here. #3166's narrow rule — catch up only when green and
BEHIND— drove the average below the queue's break-even. The remedy #3134 proposes was made unprofitable by a remedy already shipped, and nothing noticed because the two were never priced in the same unit.Price a proposal in the unit the proposal is made of. Minutes said 307 and implied a queue would help; runs said it costs more. Both are true readings of one window — only the second answers the question asked.
Stated rather than hidden: a queue wins at batch ≥ 1.33, which is a question about arrival rate rather than about the rule; and it does nothing for the other half of the tax, waiting on checks that cannot block, which
--required-onlyalready removes.tri pr-costnow prints this arithmetic itself.Posted to #3134.
SKILL.md530–531.Refs #3134