tri fmt: run the formatter and restore every file that was not yours - #3053
Merged
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 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.
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
gHashTag
added a commit
that referenced
this pull request
Sep 3, 2026
…r than master Refs #3051 Eighth collision, and the first one BETWEEN two of my own open branches rather than with master: #3053 and this one both claimed 471. Resolved with the command's own --base flag pointed at the sibling branch instead of master, which is what that flag is for and had not been used in anger before. Note for the tool: it can only see one base at a time, so N open branches still need N-1 sequential renumbers in a chosen order. It does not discover siblings.
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 3, 2026
Contributor
PR DashboardGenerated at: 2026-09-03 20:24:13 UTC
Summary
Seal Status
|
Contributor
PR DashboardGenerated at: 2026-09-03 20:57:06 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Refs #3042 Ninth collision. Resolved by tri skill renumber against origin/master.
gHashTag
added a commit
that referenced
this pull request
Sep 3, 2026
Refs #3051 Ninth collision, and the first use of --first in anger. #3053 is open with two sections that will land at 476/477, so this one starts at 478 -- numbered against the SHARED base, which is the whole point of the flag: --base pointed at that sibling would have rebuilt this file on it and carried its sections into this PR.
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.
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-03 22:01:08 UTC
Summary
Seal Status
|
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 · replaces #3044
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. 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:
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. §471 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.§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.
Evidence
cargo test -p tri --binsfmtminefilter#[test]counttri 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 here 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.Why this replaces #3044
That branch carried a repair commit with no issue reference.
Check L1 TRACEABILITYchecks every commit in the PR, so a follow-up commit cannot clear it, and the only in-place fix is a force-push — which is not done in this repository. Same tree, one commit, properly referenced.The branch it replaces is also where §471/§472 were renumbered three times (collisions six and seven), the last one resolved by
tri skill renumberitself — see #3051 and #3052.