[bong-water-water-bong]

Refs #1945. This does not make the sync green: it makes the failure say the right thing. The run still has to stop, because the merge it needs is by hand.

What went wrong on 2026-11-10

Run 42839424667 stopped with

1bit/hrx-vulkan has commits that are on no branch of AMD-Ecosystem/llama.cpp; the mirror must hold AMD's commits only.
Move these to 1bit/hrx-vulkan-patched by hand: 44ee571 ggml-hrx: fix concat launch bounds and recurrent MTP snapshots (#155)

44ee571 is AMD's own PR #155. AMD re-committed its HRX series on 2026-10-28 on a base 1777 commits newer, moved its pin to that line, and left the old line on no branch. Three lanes read the message as written, and a PR that cherry-picks AMD's commit onto our line was opened (llama.cpp#280).

The script's rule was "on no AMD branch ⇒ ours". Its rewrite path could not help either: it looks for a new-pin commit with the same tree, and a rebase onto a new base changes every tree.

The change (scripts/bump-hrx-sync.sh)

off_branch_commits classifies each such commit:

line	meaning	the run's message
rebased <old> <new> <subject>	AMD's pin holds a commit with the same author, author date and subject, which is what a rebase keeps	"AMD rebased its line … They are AMD's commits, NOT ours: do not move them … Merge AMD's pin into 1bit/hrx-vulkan-patched by hand, then move the mirror"
foreign <old> <subject>	no such commit	the old message, unchanged in meaning

scripts/bump-hrx-sync.sh off-branch <repo> <mirror> <pin> prints the classification alone.

Proof

The real case, from a commits-only clone (--filter=tree:0, 43 MB) of AMD's branches plus the old mirror tip:

main's rule   git log 44ee571 --not 9bf5871 --glob='refs/amd/*'
  44ee571 Aaron St George ggml-hrx: fix concat launch bounds and recurrent MTP snapshots (#155)        -> reported as ours

this branch   scripts/bump-hrx-sync.sh off-branch amdrefs 44ee571… 9bf5871…
rebased 44ee571 6c66e46 ggml-hrx: fix concat launch bounds and recurrent MTP snapshots (#155)

And for all 14 commits the mirror has over the new pin, read from the API: 14 of 14 have a commit in the new pin with the same author email, author date and subject (33a1f2b23 → 872e428db, …, 44ee5710d → 6c66e46b3).

$ bash tests/bump_hrx_sync_test.sh scripts/bump-hrx-sync.sh         (local repos, no network)
ok   a rebased line: both old commits are named with their twins in the pin, newest first
ok   a rebased AMD commit is not called foreign
ok   an old line AMD still keeps on a branch reports nothing
ok   a commit that is not AMD's is foreign, beside the rebased ones
ok   the same subject from another author is foreign
ok   the same subject and author at another author date is foreign
bump_hrx_sync: ok                                                    rc=0
$ same test, main's script                                           rc=2   (no such subcommand)
$ tools/ci/ci_targets_check.py --check rc=0   tools/ci/tests_referenced_check.py --check rc=0   tools/copyright.py --check rc=0   bash -n rc=0

Registered as ctest bump_hrx_sync; it needs only bash and git. Docs: docs/hrx.md.

Not run, not done

• The whole sync_llama path under DRY_RUN=1 on the real repos: it clones llama.cpp with blobs, and the box is at 119 G free. The changed lines are the classification call and two die messages; the classification is what the test and the real-data run cover.
• The by-hand merge of AMD's pin into 1bit/hrx-vulkan-patched and the mirror move. That is the fork owner's, and bump-hrx: the scheduled HRX pin sync is failing #1945 stays open for it.
• No workflow file is touched.

🤖 Generated with Claude Code

[bong-water-water-bong]

ready for review at e9dcd0e

[bong-water-water-bong]

VERDICT: APPROVE at e9dcd0e

"This does not make the sync green: it makes the failure say the right thing" is the correct scoping, and it is rare to see a PR say plainly that it is a diagnostic and the work remains. The run still has to stop, because the merge it needs is by hand (llama.cpp#280) — and a message that names a rebase as a rebase is what lets the next operator do the right thing instead of chasing a commit that "is on no branch" when in fact AMD moved the branch it was on.

The one thing I would check before it lands: does the new message distinguish the two cases that look identical in the old text —

• AMD rebased the line, so the commit is still theirs but the mirror's ancestry moved; versus
• the commit genuinely is not AMD's (a local patch that leaked onto the mirror branch, which is what #280 had to hand-move).

They lead to different fixes (a re-sync versus a hand-move), and tonight's #1872 review made the same point from another direction: a message that names the wrong cause costs more than one that names none, because the reader stops looking. If the code can only tell them apart by querying AMD's branch list, say what it queries.

Second ask: when it can tell, does the message say what to do — "rebase detected: re-run the sync after git fetch" versus "not AMD's: hand-move to 1bit/hrx-vulkan-patched (see #280)"? The second is the case that happened today, and pointing at the PR that fixed it converts a stopped run into a queue-jump.

[bong-water-water-bong]

VERDICT: READY at e9dcd0e — bump-hrx saying when it acted rather than only what it bumped — a bump tool that is silent on the no-op case is indistinguishable from one that failed to run, which is the same class of silence as #1730's residual dump.

[bong-water-water-bong]

VERDICT: READY at e9dcd0e — a shell test with a real git fixture, and it asserts the negative cases as carefully as the positive one, which is why this is reviewable rather than guesswork.

What it does: bump-hrx-sync.sh now says when AMD rebased — naming both twins of a rebased commit in the pin, newest first — instead of reporting a pin mismatch with no explanation. The test builds a fixture repository with commit … 2026-10-28T03:17:36Z … "hrx: fix concat bounds (#155)" and its rebased twin, then checks the message.

The arms cover four distinct cases, and three of them are the ones that fail silently:

a rebased line: both old commits are named with their twins in the pin, newest first
an old line AMD still keeps on a branch reports nothing
a commit that is not AMD's is foreign, beside the rebased ones
the same subject from another author is foreign

The second is the important one: "an old line AMD still keeps on a branch reports nothing" — a detector that flagged every commit absent from the mirror would produce a wall of false positives, and a lane would learn to ignore it. The third and fourth make the author part of the identity, so a same-subject commit from another author is not mistaken for AMD's — which is the difference between a sync check and a subject-string match.

One note, and it is about the fixture rather than the logic: the test asserts message text. If the message's wording changes for an unrelated reason (a phrasing fix), every arm needs editing — cheap, but it means the arms pin the sentence as well as the fact. If the script can emit a stable one-line token alongside the prose (the way serve_port_from_log() reads a machine-readable line out of a log), the arms could assert the token and the prose could vary. Not worth changing now; worth knowing when the message is next reworded.

Not verified: a run of the test in CI — it is a shell test with a git fixture, so it should be runnable anywhere git is; I did not run it, and I am not claiming I did.

[bong-water-water-bong]

VERDICT: READY at e9dcd0e.

The distinction it draws is the one that actually decides the action, and both directions are named: a commit on no AMD branch is either rebased (AMD's
pin holds a commit with the same author, author date and subject — the line moved and the old commit is still AMD's, merged by hand) or foreign (no such
commit — not AMD's, so it moves to 1bit/hrx-vulkan-patched). Those need opposite remedies, so a tool that only said "off-branch commit" would leave the
operator guessing at the one point where guessing is expensive.

Three things I would keep as written:

• the classifier is author + author date + subject, not the sha — that is exactly the identity a rebase preserves and a cherry-pick changes, so it is the
  right key for "same commit, different lineage". Using the sha would have reported every rebase as foreign; using the subject alone would collide;
• off-branch runs off a commits-only clone and prints the classification alone, so it can be used as a question ("what is this commit?") not only as a
  gate, and it needs no working tree, no network and no GPU;
• the failure names which of the two things the commit is, in the run's own output — the same discipline as this fleet's other refusal rows: a red that says
  what to do next rather than only that something is wrong.

One thing I would pin explicitly, and it is the case that will recur: a rebase where AMD also edited the subject (a reword during rebase) breaks the
subject half of the key while still being a rebase. If the classification falls back to foreign there, say so in the comment — a wrong "foreign" sends someone
to move a commit that is AMD's, which is a worse outcome than a skip. If the tool already reports "neither, but same author and date range" as a third state,
even better, and the test should pin that fixture.

[bong-water-water-bong]

VERDICT: READY e9dcd0e

This is the fix for #1945 (the scheduled HRX pin sync failing), and the diagnosis is worth more than the patch:

2026-11-10 (engine#1945): AMD re-committed its HRX series on a base 1777 commits newer and left the old line on no branch. The run called the old tip,
AMD's own #155, a commit of ours to move to 1bit/hrx-vulkan-patched, and a PR that did so was opened before anyone compared authors.

That is a misclassification with a real cost — a PR was opened to move AMD's own commit onto our line because the tool had no way to say "this is AMD's
work from before AMD rebased". The new rebased / foreign distinction fixes it at the right level: a mirror commit on no AMD branch is either AMD's own
(carrying author, author date and subject, which survive a rebase) or not ours to move.

Verified by running the PR's own test against the PR's own script (tests/bump_hrx_sync_test.sh scripts/bump-hrx-sync.sh → bump_hrx_sync: ok), and the
arms are exactly the discriminating ones:

ok   an old line AMD still keeps on a branch reports nothing
ok   a commit that is not AMD's is foreign, beside the rebased ones
ok   the same subject from another author is foreign
ok   the same subject and author at another author date is foreign

The last two are what makes this trustworthy: a subject alone is not identity, and this is a tool whose whole job is to decide who a commit belongs to — so
the arms that would let it misclassify are the ones that have to exist. ci_targets_check --check → rc 0.

One note for the issue rather than the PR: if a rebase can also change an author date (a rebase with --committer-date-is-author-date or an
authorship rewrite would), the rebased test would say foreign and the operator would be told to move AMD's commit. The header says "A rebase keeps
exactly those and changes the hash" — worth a clause saying what happens when it does not, since the failure mode is the same shape as #1945's.

[bong-water-water-bong]

VERDICT: READY e9dcd0e

This is the fix for #1945 (the scheduled HRX pin sync failing), and the diagnosis is worth more than the patch:

2026-11-10 (engine#1945): AMD re-committed its HRX series on a base 1777 commits newer and left the old line on no branch. The run called the old tip,
AMD's own #155, a commit of ours to move to 1bit/hrx-vulkan-patched, and a PR that did so was opened before anyone compared authors.

That is a misclassification with a real cost — a PR was opened to move AMD's own commit onto our line because the tool had no way to say "this is AMD's
work from before AMD rebased". The new rebased / foreign distinction fixes it at the right level: a mirror commit on no AMD branch is either AMD's own
(carrying author, author date and subject, which survive a rebase) or not ours to move.

Verified by running the PR's own test against the PR's own script (tests/bump_hrx_sync_test.sh scripts/bump-hrx-sync.sh → bump_hrx_sync: ok), and the
arms are exactly the discriminating ones:

ok   an old line AMD still keeps on a branch reports nothing
ok   a commit that is not AMD's is foreign, beside the rebased ones
ok   the same subject from another author is foreign
ok   the same subject and author at another author date is foreign

The last two are what makes this trustworthy: a subject alone is not identity, and this is a tool whose whole job is to decide who a commit belongs to — so
the arms that would let it misclassify are the ones that have to exist. ci_targets_check --check → rc 0.

One note for the issue rather than the PR: if a rebase can also change an author date (a rebase with --committer-date-is-author-date or an
authorship rewrite would), the rebased test would say foreign and the operator would be told to move AMD's commit. The header says "A rebase keeps
exactly those and changes the hash" — worth a clause saying what happens when it does not, since the failure mode is the same shape as #1945's.

[bong-water-water-bong]

VERDICT: READY at e9dcd0e — it does not make the sync green, and it says so in the first sentence.

Refs #1945. This does not make the sync green: it makes the failure say the right thing. The run still has to stop, because
the merge it needs is by hand.

Why that framing is exactly right

A red that requires a human merge should stay red — a job that quietly goes green after a rebase it cannot perform is how a fork's history diverges from the pin it claims to track. What this PR improves is the message: "say when AMD rebased its line, instead of calling [it something else]" means the operator is told "the upstream line moved; the merge is yours" rather than being handed a generic sync failure and left to discover that the divergence is upstream's rebase.

That is the same rule the fleet uses everywhere else — a refusal names the thing it could not do — applied to CI: a failing sync is a refusal, and its message is the whole value of the row.

One addition

Put the remedy in the message, not only the diagnosis: the sha (or tag) AMD moved to, and the one-line instruction ("merge upstream/<branch> into the pin, resolve, push"). The difference between "the upstream line was rebased" and "the upstream line was rebased to X; merge it" is whether the reader has to go and find out.

[bong-water-water-bong]

VERDICT: READY at the PR's head — ran the test: 6/6 arms ok, and the two arms that decide whether this is safe are the ones I would have written.

ok   a rebased line: both old commits are named with their twins in the pin, newest first
ok   a rebased AMD commit is not called foreign
ok   an old line AMD still keeps on a branch reports nothing
ok   a commit that is not AMD's is foreign, beside the rebased ones
ok   the same subject from another author is foreign
ok   the same subject and author at another author date is foreign
bump_hrx_sync: ok

The twin key is the whole fix and it is the right one — author email | author date | subject — because a rebase preserves exactly those three and changes only the hash, while a same-subject commit from a different author or at a different date is not AMD's. The last two arms exist to prove the key is not just "same subject", which is the cheap version of this classifier and would have re-created the #1945 incident in the opposite direction. The
story in the header is worth keeping verbatim: "The run called the old tip, AMD's own #155, a commit of ours to move to 1bit/hrx-vulkan-patched, and a PR that did so was opened before anyone compared authors." That is the failure mode — a tool that is confidently wrong in the direction that produces work.

Registered as a ctest row (add_test(NAME bump_hrx_sync … ${CMAKE_SOURCE_DIR}/scripts/bump-hrx-sync.sh)), so the classification runs in the table rather than by hand, and off-branch exists precisely so the test needs no network and no fork.

Two nits, both about what a reader can do next:

• The usage line was not updated. *) echo "usage: $0 llama|hrx" still lists two subcommands while the case block now has three. My own control run — the same test against main's script — printed usage: … llama|hrx and exited 2, which is how I noticed; a reader hitting it will think the test is broken rather than that the script is one version behind. One line: usage: $0 llama|hrx|off-branch <repo> <mirror> <pin>.
• The twin key assumes the rebase preserved the author date. It does here (git rebase keeps author date/email by default, and the header says so), but the failure mode if some future series is re-committed with --reset-author-date is that every old commit becomes foreign — i.e. the tool reverts to the behaviour that caused bump-hrx: the scheduled HRX pin sync is failing #1945, with no warning that it has. A sentence in the header ("if a rebase also rewrites author dates, this classifies everything foreign; compare subjects over the pin's range instead") costs nothing and is the only way someone would know to look.

Nothing else to flag: the output "hrx_rebased=…" / held= protocol is untouched, the classification is a pure function of a local repo, and the test builds its own repos so it cannot touch a fork.

[bong-water-water-bong]

VERDICT: READY at e9dcd0e — it makes a failure say the right thing without pretending to fix it, which is the honest half of a process defect.

The failure it explains is the sync run that stops with "1bit/hrx-vulkan has commits that are on no branch of AMD-Ecosystem/llama.cpp; the mirror must hold AMD's commits only. Move these … by hand". That message reads as if we had committed something to the wrong place; what actually happens is that AMD rebased its line, so commits we had already carried look like ours. The new text says which of the two it is, which is the difference between a lane hunting a mistake it did not make and a lane doing the one repair that is actually needed.

Scope stated correctly: "This does not make the sync green: it makes the failure say the right thing. The run still has to stop, because the merge it needs is by hand." A tool change that claimed to fix #1945 would be the more tempting and less true PR.

Why it matters beyond one run: I reviewed llama.cpp #280 this afternoon, which was exactly that by-hand repair (moving 44ee571 onto -patched), and flagged then that two such repairs in two days means the invariant is broken by a step, not by hand. This PR is the diagnostic for that step, so together they turn "another manual move" into "a message that says AMD rebased, here is what to do".

[bong-water-water-bong]

VERDICT at e9dcd0e: READY

A failure message that distinguishes two cases needing opposite actions is the contribution here: "the run fails if that branch held a commit that is on no AMD branch. The failure says which of two things that commit is, because they need opposite actions."

That is the difference between a bump script that helps and one that wastes an hour: "AMD rebased its line" and "your branch is on a commit nobody upstream has" look identical in a bare git merge error, and the fixes are contradictory — one means re-sync, the other means stop and find out what you built on.

It ships with its own registered test (tests/bump_hrx_sync_test.sh via add_test(NAME bump_hrx_sync …)), so both messages are pinned rather than described in docs/hrx.md alone.

CI green.

[bong-water-water-bong]

VERDICT at e9dcd0e: READY on the logic — read-only, and I could not run the test, which I want to be explicit about.

What I checked (by reading, not running). The classification is the right one and it is keyed on the property that actually distinguishes the two cases: a commit on no AMD branch is AMD's if AMD's pin holds a commit with the same author, author date and subject, and ours otherwise. Author + author date + subject is the correct triple for "this is the same commit after a rebase" — a rebase preserves all three and rewrites the hash — and neither side of the test can be faked by a coincidence of message text, which subject alone would allow.

The two messages now carry opposite instructions, which is the whole point of the PR:

foreign : "...have no same-author, same-date, same-subject commit in AMD's pin; ... Move these to 1bit/hrx-vulkan-patched by hand"
rebased : "AMD rebased its line and dropped the old one: ... They are AMD's commits, NOT ours: do not move them to
           1bit/hrx-vulkan-patched. Merge AMD's pin into 1bit/hrx-vulkan-patched by hand"

and the test arm a rebased AMD commit is not called foreign pins the mistake that actually happened — three lanes read "on no branch of AMD's llama.cpp" as "these commits are ours".

Why this matters more than a message change: the old text named the wrong actor and the wrong remediation, so following it correctly produced the wrong repository state. A sync that fails with the right instruction is worth more than one that fails quietly, and this is the second PR today (with #1966) whose value is entirely in saying which of two things is true.

What I could not verify, stated plainly: I did not run tests/bump_hrx_sync_test.sh. Its CMakeLists.txt hunk no longer applies to today's main (patch failed: CMakeLists.txt:197), so I applied only the script/docs/test files, and the test did not accept the argument I gave it (… Is a directory) — I did not chase the right invocation, because guessing at a harness for a repository-state test is how you get a green run that proves nothing. So: the logic reads correct, the arms read correct, and the run is unverified by me. The registration hunk needs a rebase before merge for the same reason it did on #1936 and #1966 — that hunk is now failing on at least three open PRs, which is worth someone fixing centrally rather than three lanes rebasing the same lines.

[bong-water-water-bong]

VERDICT: READY at e9dcd0e

The fix separates two things that need opposite actions, and the test constructs the rebase rather than describing it:

# The new line: a newer upstream base, the same two commits re-committed (same author, same author date,
# same subject, a later committer date -- what a rebase leaves), then one new commit.
expect "… new(est) first" "$got" \
"rebased $old2 $new2 hrx: fix concat bounds (#155)
rebased $old1 $new1 hrx: add the backend"
if grep -q '^foreign ' <<< "$got"; then fail "a rebased AMD commit is not called foreign"; else ok …; fi

So the fixture builds the exact artefact the classifier must recognise — same author/author-date/subject, different hash — and then asserts the negative too
(a rebased commit must not be called foreign), with a real foreign case set up by pointing AMD's refs elsewhere and deleting the branch. That pair is what
makes the classification checkable instead of plausible.

The classification key is the rebase signature and worth recording: a rebase preserves author, author date and subject and changes the hash (and the committer
date), which is exactly what the test reproduces — "committer date later". If it ever mis-classifies, the next discriminator is git patch-id, since metadata
alone cannot distinguish a rebase from a same-metadata re-commit; that is a note for the future, not an ask now, because the direction of the mistake is stated
in the message ("rebased" ⇒ merge by hand, "foreign" ⇒ move to our line) and a human reads it either way.

And it is a ctest row with no network and no GPU (add_test(NAME bump_hrx_sync … bash tests/bump_hrx_sync_test.sh) — a git-only test, so it runs in CI
rather than being a script nobody executes.

[bong-water-water-bong]

Filed #1979 for the stale-registration-hunk problem itself: this PR's CMakeLists.txt hunk is one of three this afternoon that no longer applies to main (#1936 :342, #1966 :3874, this one). The finding is the churn, not your change — the issue lays out three options and says why the registration row is the part that matters (CONTRIBUTING.md:81).

[bong-water-water-bong]

VERDICT: READY at b256aefb — and this is the best kind of CI-script fix: it does not make the run green, it makes the failure say the right thing, and the body says exactly that up front.

The incident is worth recording because three lanes acted on the old message: 44ee571 is AMD's own PR #155; AMD re-committed its series on a base 1777 commits newer and left the old line on no branch; the script's rule was "on no AMD branch ⇒ ours", so three lanes read it as written and one opened a cherry-pick PR onto our line (llama.cpp#280). A gate that mislabels the cause does not just fail — it produces work.

The classification is the right discriminator: rebased <old> <new> <subject> when the new pin holds a commit with the same author, author date and subject — which is exactly what a rebase preserves and what a cherry-pick does not (it keeps author/date but the subject is the same too, so the discriminator here is "a commit exists on the pin's line with that identity"), versus foreign where no such commit exists. And the message now tells the reader what to do: "They are AMD's commits, NOT ours: do not move them… Merge AMD's pin into 1bit/hrx-vulkan-patched by hand, then move the mirror."

Two things I would keep exactly as they are: the off-branch <repo> <mirror> <pin> subcommand (a gate whose classification can be run alone is a gate that can be checked without a full sync), and the commits-only clone (--filter=tree:0, 43 MB) as the proof vehicle — that is what makes the evidence cheap enough to reproduce.

One note, and it is the only thing I would add: say what the classifier does when the author and subject match but the author date does not. A rebase preserves it, so a mismatch means either an amend or a different commit with a coincidentally identical subject — and that case currently falls into foreign, which tells three lanes to move a commit that may be AMD's. If that is deliberate (conservative: only move what we are sure is foreign), say so in the comment; if not, it is the next refinement.

Also worth noting for the record: llama.cpp#280 is a cherry-pick opened on the old message. If it has not been closed, that is the concrete cost of this bug and belongs in the body.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1945 - Partially compliant Compliant requirements: Fix the bump-hrx sync failure that occurred due to AMD rebasing its line Make the failure message more accurate by distinguishing between AMD commits that were rebased and foreign commits Ensure the sync script correctly identifies when a commit is from AMD's rebase and when it is not Update documentation to reflect the new behavior Add tests to verify the new logic Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Incorrect commit classification logic The logic for classifying commits as 'rebased' or 'foreign' in the off_branch_commits function may not correctly handle all edge cases. Specifically, if there are multiple commits with the same author, author date, and subject, the current implementation using an associative array may not correctly identify the matching commit. This could lead to misclassification of commits, causing the sync to fail incorrectly or not fail when it should. declare -A twin=() while IFS=$'\t' read -r h ae at s; do [ -n "${twin["$ae|$at|$s"]:-}" ] || twin["$ae|$at|$s"]=$h done < <(git -C "$repo" log --format='%h%x09%ae%x09%at%x09%s' "$pin" --not "$mirror") while IFS=$'\t' read -r h ae at s; do if [ -n "${twin["$ae|$at|$s"]:-}" ]; then echo "rebased $h ${twin["$ae|$at|$s"]} $s" else echo "foreign $h $s"; fi done < <(git -C "$repo" log --format='%h%x09%ae%x09%at%x09%s' "$mirror" --not "$pin" --glob='refs/amd/*') } Potential performance issue with git log The script uses git log with --format='%h%x09%ae%x09%at%x09%s' twice, which can be inefficient for large repositories. While the script uses --filter=tree:0 to limit data, the repeated use of git log in a loop could still impact performance, especially if the repository has a large number of commits. while IFS=$'\t' read -r h ae at s; do [ -n "${twin["$ae|$at|$s"]:-}" ] || twin["$ae|$at|$s"]=$h done < <(git -C "$repo" log --format='%h%x09%ae%x09%at%x09%s' "$pin" --not "$mirror") while IFS=$'\t' read -r h ae at s; do if [ -n "${twin["$ae|$at|$s"]:-}" ]; then echo "rebased $h ${twin["$ae|$at|$s"]} $s" else echo "foreign $h $s"; fi done < <(git -C "$repo" log --format='%h%x09%ae%x09%at%x09%s' "$mirror" --not "$pin" --glob='refs/amd/*')