tri fmt: run the formatter and restore every file that was not yours - #3044
Closed
gHashTag wants to merge 5 commits into
Closed
tri fmt: run the formatter and restore every file that was not yours#3044gHashTag wants to merge 5 commits into
gHashTag wants to merge 5 commits into
Conversation
Closes #3042 `cargo fmt --all` on a one-file change leaves 165 files dirty, 164 of them collateral, including bootstrap/src/compiler.rs -- M5-frozen, so the freeze gate goes red as a side effect of tidying another crate. `-p t27c` produced 155 earlier this week. Nothing keeps this tree formatted: no workflow invokes cargo fmt or rustfmt. An unformatted tree is this repository's normal state, so running the formatter is not a fix, it is a 164-file diff on top of your own. `tri fmt` takes the dirty set, runs the formatter, and restores every file that was clean before and is dirty after. Clean-before means identical to HEAD, so the restore loses nothing -- which is why the dirty set is taken first rather than derived from a base ref. Measured on this repository: 165 dirty, 1 kept, 164 restored, FROZEN_HASH intact afterwards. Every restored path is printed. Sections 466 and 467. 466 is the reason this is a command and not a note: the skill already recorded this four times -- 72, 381, 407, 447 -- and the command was run anyway. When a rule has been written down repeatedly and broken anyway, the next unit of work is an executable. 467 is the empty-population half of #3025, kept here because it is the same shape: a guard written for one way of producing no numbers did not cover the other. Two limits, both stated in the module and the section rather than left to be found. It cannot help with the file you are editing: formatting the thirteen lines added to main.rs also sorted that file's mod declarations, 13 insertions reported as 31 insertions and 18 deletions. And a concurrent process sharing the worktree can dirty a file between the two git status calls and have it reverted; separate worktrees are unaffected, git checkout being per-worktree unlike git stash.
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 3, 2026
Fifth section-number collision on .claude/skills/ci-gates/SKILL.md: master took 466 and 467 in #3043 while this branch was open. Resolved by rebuilding from origin/master and re-appending my two sections as 468 and 469 -- the master prefix is byte-identical, and the file is 433 sections, all unique and ascending. 468 is "A lesson written down four times, and the command run anyway". 469 is "The machine that could not answer, and the population nobody asked".
Owner
Author
Renumbered after a collision — §466/§467 are now §468/§469Master took 466 and 467 in #3043 while this branch was open. That is the fifth number collision on this file for me. Resolved by rebuilding from
The master prefix is byte-identical (asserted, not eyeballed), and Everywhere the PR description above says §466 or §467, read §468 and §469. |
Contributor
PR DashboardGenerated at: 2026-09-03 19:10:49 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 3, 2026
master took 468-470 while this branch was open. Mine move to 471 and 472. The master prefix is asserted byte-identical, not eyeballed.
This was referenced Sep 3, 2026
…ion) The command's first real use, and it found its own gap: the byte-prefix test refused because master had REWORDED an existing section while this branch was open, so the file was an older base plus a tail rather than any commit's file plus an append. Falls back to identifying the tail by shared section TITLES, and says which method it used. Numbers were already right (471, 472); the base region was stale, so the file is rebuilt on origin/master with my two sections re-appended. Master prefix asserted byte-identical.
Contributor
PR DashboardGenerated at: 2026-09-03 19:55:50 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
… last line The first real use of `tri skill renumber` shipped a defect and this commit is the repair. A tail identified by TITLE starts at its first `## ` heading with no leading newline, and concatenating it onto a trimmed base put that heading in the middle of a line -- so it stopped being a heading. 436 sections became 435, and the COUNT is what caught it, not reading the file. Fixed in the tool with an explicit joiner plus a pre-write guard that refuses unless the rebuilt file has exactly base + tail sections. Both are tested and the joiner mutant is killed. Here: 436 sections, master prefix asserted byte-identical, my two sections at 471 and 472.
Contributor
PR DashboardGenerated at: 2026-09-03 19:58:21 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Owner
Author
|
Superseded by #3053 — same tree, one commit, properly referenced.
Everything measured on this branch stands and is restated in #3053: 165 dirty / 1 kept / 164 restored, |
gHashTag
added a commit
that referenced
this pull request
Sep 3, 2026
…3053) * tri fmt: run the formatter and restore every file that was not yours Closes #3042 `cargo fmt --all` on a one-file change leaves 165 files dirty, 164 of them collateral, including bootstrap/src/compiler.rs -- M5-frozen, so the freeze gate goes red as a side effect of tidying another crate. `-p t27c` produced 155 earlier this week. Nothing keeps this tree formatted: no workflow invokes cargo fmt or rustfmt. An unformatted tree is this repository's normal state, so running the formatter is not a fix, it is a 164-file diff on top of your own. `tri fmt` takes the dirty set, runs the formatter, and restores every file that was clean before and is dirty after. Clean-before means identical to HEAD, so the restore loses nothing -- which is why the dirty set is taken first rather than derived from a base ref. Measured on this repository: 165 dirty, 1 kept, 164 restored, FROZEN_HASH intact afterwards. Every restored path is printed. Sections 471 and 472. 471 is the reason this is a command and not a note: the skill already recorded this four times -- 72, 381, 407, 447 -- and the command was run anyway. When a rule has been written down repeatedly and broken anyway, the next unit of work is an executable. 472 is the empty-population half of #3025, kept here because it is the same shape: a guard written for one way of producing no numbers did not cover the other. Two limits, both stated in the module and the section rather than left to be found. It cannot help with the file you are editing: formatting the thirteen lines added to main.rs also sorted that file's mod declarations, 13 insertions reported as 31 insertions and 18 deletions. And a concurrent process sharing the worktree can dirty a file between the two git status calls and have it reverted; separate worktrees are unaffected, git checkout being per-worktree unlike git stash. Replaces the branch behind #3044, which carried a repair commit with no issue reference. L1 checks every commit and there is no way to fix a pushed commit message without a force-push, which is not done here. * Renumber to 477/478 with the merged tri skill renumber Refs #3042 Eleventh collision. Two process notes from this one. The renumber ran twice against a STALE binary before this: the merge was left uncommitted (conflicts resolved but not concluded), so renum.rs was not in the tree and `tri skill renumber` answered with its usage text. The check printed OK=False and prefix-identical False, and this time I stopped on it instead of pushing -- which is the whole difference from the repair two commits earlier. And master moved between the fetch and the merge, so the first completed merge still did not have origin/master as an ancestor. Loop until it does, then build, then renumber, then verify -- in that order, each step read.
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.
Closes #3042
Measured, in this repository
cargo fmt --allon a one-file changebootstrap/src/compiler.rs, M5-frozen — the freeze gate goes redcargo fmt -p t27con a two-file change, earlier this weekcargo fmtorrustfmtNothing keeps this tree formatted, which is why it is unformatted. So running the formatter is not a tidy-up — it is a 164-file diff authored on top of your own change, plus a broken content hash.
What the command does
Take the dirty set, run the formatter, restore every file that was clean before and is dirty after. Clean-before means identical to
HEAD, so the restore loses nothing — and that is the whole reason the dirty set is taken first rather than derived from a base ref.End-to-end on this worktree:
165 dirty, 1 kept, 164 restored, FROZEN_HASH intact. Every restored path is printed.--dry-runreports the dirty count and whether any workflow formats, without running anything.Why a command and not a note
It is already a note, four times: §72 (150 files, same frozen file, same grep), §381, §407, §447. It was recorded four times and the command was run anyway, this week. §466 says that plainly — when a rule has been written down repeatedly and broken anyway, the next unit of work is an executable, not another paragraph — and the count of prior sections is the evidence, taken with
grep -cbefore appending.§467 is the empty-population half of #3025, kept in this PR because it is the same shape: a guard written for one way of producing no numbers did not cover the other.
Evidence
cargo test -p tri --binsfmtminefilter#[test]in the moduletri skill checkMutation:
Two limits, stated rather than left to be found
main.rsalso sorted that file'smoddeclarations, and a 13-insertion diff was reported as 31 insertions and 18 deletions. This is §447 arriving inside the new tool. The tell is the shape: deletions on a pure addition. The diff in this PR is 13 insertions, 0 deletions, because the file was checked out and the hunks re-applied by hand.git statuscalls and have it reverted. The window is the formatter's runtime; every restored path is printed for that reason. Separate worktrees are unaffected —git checkoutis per-worktree, unlikegit stash.