Stop tracking tmp/ scratch output and ignore the directory - #4
Merged
acoliver merged 1 commit intoSep 6, 2026
Merged
Conversation
Commit e675674 accidentally tracked three scratch files: an automated code-review dump of this repository's own PR janfeddersen-wq#66, its empty stderr companion, and a commit message draft. These are artifacts of the review and commit workflow rather than source, so they do not belong in version control. tmp/ is where local verification output is written, and the ignore rules covered *.log and logs/ but not this directory, which is how the files slipped in. A tmp/ rule prevents the same accident from recurring. The files remain on disk, now untracked.
Owner
Author
|
One reason to land this before janfeddersen-wq#66 goes in rather than after. Upstream janfeddersen-wq#66 currently shows all four checks passing (Check, Clippy, Format, Test) with no open review threads, so it is ready to merge whenever jan gets to it. That CI run was computed on the branch as it stands, which means the tree those green checks validated includes Merging this first means the scratch files never reach upstream and janfeddersen-wq#66 gets a fresh run on a clean tree. Merging it after means they land in Either order works, and neither is urgent. This is only cheaper now. |
acoliver
added a commit
that referenced
this pull request
Sep 7, 2026
Commit e675674 accidentally tracked three scratch files: a code-review dump, its stderr companion, and a commit message draft. They are workflow artifacts, not source. This restores the state merged to the remote in PR #4 so the rebase force-push does not undo it, and adds a tmp/ ignore rule to prevent a recurrence. The files remain on disk, now untracked.
acoliver
added a commit
that referenced
this pull request
Sep 7, 2026
Commit e675674 accidentally tracked three scratch files: a code-review dump, its stderr companion, and a commit message draft. They are workflow artifacts, not source. This restores the state merged to the remote in PR #4 so the rebase force-push does not undo it, and adds a tmp/ ignore rule to prevent a recurrence. The files remain on disk, now untracked.
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
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.
e675674committed three files that look like local scratch output rather than source:tmp/ocr-pr66/review.jsontmp/ocr-pr66/review.stderrtmp/commitmsg.txtThey are tracked on
feature/issue-65-open-responses, which is the head of the open upstream PR, so they are currently part of the diff that PR presents for review.The cause is a gap in
.gitignore: it covers*.logandlogs/but has no rule fortmp/, which is where local verification output gets written. Anything in there without a.logextension is addable, so this can happen again, and it nearly did while I was working on the steering branch (a verification exit-code sentinel would have been caught by exactly the same gap).This
git rm --cacheds the three paths, leaving them on disk, and adds a singletmp/line to the existing "# Logs" section of.gitignore. Nothing else is touched: no Rust source, no manifests, no changelog, no workflows.Verification
git ls-files tmp/returns nothinggit check-ignore -v tmp/anything.txtreports.gitignore:68:tmp/cargo check --workspace --all-featuresexits 0, confirming the removal touched nothing the build depends onThe staged diff is exactly four files: one added line, three deletions.
Why this targets the feature branch
Based on
feature/issue-65-open-responsesso it can land before that branch goes upstream, rather than carrying the scratch files into janfeddersen-wq#66. It is independent of the steering work in #3; the two touch no common files.