chore: untrack the b2 output committed with the hash policies - #117
Merged
Merged
Conversation
boostorg#103 brought 415 files of b2 output into the tree - 106 `.o`, 8 `.so`, the test executables, their `.run`/`.output`/`.test` stamps, and the `bin/config.log` and `bin/project-cache.jam` at the root. 613 MiB expanded, 94 MiB in the pack. `bin/` has been ignored since boostorg#108, which landed four days before boostorg#103 was merged and said what would happen without it: "leaving the object trees permanently untracked-but-addable - `git add test` would commit tens of thousands of lines of objects". feature/hash-policies was cut before that commit, so the rule was not in its .gitignore, and a rule added later does not apply to a path that is already tracked. The merge carried the files in. Two of them are written on every b2 invocation, so `git status` came up dirty after any local build. `git rm -r --cached` only: the files stay on disk, the ignore rule now takes effect, and nothing is rewritten. The blobs remain reachable through `refs/pull/103/head`, which cannot be deleted, so a rewrite of develop would break the superproject's pinned submodule SHAs without actually removing them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
An automated preview of the documentation is available at https://117.openmethod.prtest3.cppalliance.org/libs/openmethod/doc/html/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-09-17 22:58:03 UTC |
jll63
added a commit
to jll63/openmethod
that referenced
this pull request
Sep 17, 2026
boostorg#103 merged 415 files of b2 output - 613 MiB expanded, 94 MiB in the pack, on a repository of about 3 MB - days after boostorg#108 added the `bin/` ignore rule intended to prevent it. The branch was cut before that rule landed, and an ignore rule does not apply to a path that is already tracked, so the merge carried them in. Nothing in the build or the review catches this, and boostorg#117 could only untrack them: the superproject pins this library by SHA and its bot bumps the pin within minutes of every merge, so rewriting `develop` orphans commits `boostorg/boost` already points at - and would not even remove the blobs, which stay reachable through `refs/pull/<n>/head`. Write the rule down where the workflow is: stage named paths, never `git add <dir>`, and ask before committing a build artefact or any file over 1MB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
jll63
added a commit
to jll63/openmethod
that referenced
this pull request
Sep 19, 2026
boostorg#103 merged 415 files of b2 output - 613 MiB expanded, 94 MiB in the pack, on a repository of about 3 MB - days after boostorg#108 added the `bin/` ignore rule intended to prevent it. The branch was cut before that rule landed, and an ignore rule does not apply to a path that is already tracked, so the merge carried them in. Nothing in the build or the review catches this, and boostorg#117 could only untrack them: the superproject pins this library by SHA and its bot bumps the pin within minutes of every merge, so rewriting `develop` orphans commits `boostorg/boost` already points at - and would not even remove the blobs, which stay reachable through `refs/pull/<n>/head`. Write the rule down where the workflow is: stage named paths, never `git add <dir>`, and ask before committing a build artefact or any file over 1MB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
jll63
added a commit
to jll63/openmethod
that referenced
this pull request
Sep 19, 2026
boostorg#103 merged 415 files of b2 output - 613 MiB expanded, 94 MiB in the pack, on a repository of about 3 MB - days after boostorg#108 added the `bin/` ignore rule intended to prevent it. The branch was cut before that rule landed, and an ignore rule does not apply to a path that is already tracked, so the merge carried them in. Nothing in the build or the review catches this, and boostorg#117 could only untrack them: the superproject pins this library by SHA and its bot bumps the pin within minutes of every merge, so rewriting `develop` orphans commits `boostorg/boost` already points at - and would not even remove the blobs, which stay reachable through `refs/pull/<n>/head`. Write the rule down where the workflow is: stage named paths, never `git add <dir>`, and ask before committing a build artefact or any file over 1MB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
jll63
added a commit
that referenced
this pull request
Sep 19, 2026
…e notes (#118) * doc: correct two stale notes in CLAUDE.md's registry-affinity section Both were falsified by changes that did not update the prose around them. #113 collapsed the "Two things deliberately do not participate" bullets into one sentence, because `use_classes` had just started participating - but then named two things under "One thing": the interop headers and the C++26 `register_classes`. Restore the bullet form for the two that are left. The same sentence says the `any` and `type_erasure` interop headers "are untouched". #116 touched all three of them, and had to: #113 gave `virtual_` a registry parameter, and their `validate_method_parameter` specializations still spelled `virtual_<T>`, which after the change matches only the defaulted argument. What survives is the affinity claim, which is the point of the paragraph - a `virtual_any` contributes none. Say that, and record why a specialization there cannot go back to the bare spelling. The PCH paragraph names `test_capture_errors.hpp` as the only header that carries the override on a test's behalf. `test/CMakeLists.txt` has scanned for `test_checked_registry.hpp` as well since #93; the sentence three lines above, "do not add a fourth marker", already counts three. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * doc: state the rule against committing build output #103 merged 415 files of b2 output - 613 MiB expanded, 94 MiB in the pack, on a repository of about 3 MB - days after #108 added the `bin/` ignore rule intended to prevent it. The branch was cut before that rule landed, and an ignore rule does not apply to a path that is already tracked, so the merge carried them in. Nothing in the build or the review catches this, and #117 could only untrack them: the superproject pins this library by SHA and its bot bumps the pin within minutes of every merge, so rewriting `develop` orphans commits `boostorg/boost` already points at - and would not even remove the blobs, which stay reachable through `refs/pull/<n>/head`. Write the rule down where the workflow is: stage named paths, never `git add <dir>`, and ask before committing a build artefact or any file over 1MB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
2 participants
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.
(Written by Claude Code, on behalf of @jll63.)
#103 brought 415 files of b2 output into the tree: 106
.o, 8.so, the testexecutables, their
.run/.output/.teststamps, andbin/config.logandbin/project-cache.jamat the root. 613 MiB expanded, 94 MiB in the pack, on arepository that was about 3 MB.
bin/has been ignored since #108, which landed four days before #103 wasmerged and said exactly what would happen without it:
feature/hash-policieswas cut before that commit, so the rule was not in its.gitignore, and a rule added later has no effect on a path that is alreadytracked. The merge carried the files in.
Beyond the size, two of them (
bin/config.log,bin/project-cache.jam) arerewritten on every b2 invocation, so
git statuscame up dirty after any localbuild.
This is
git rm -r --cachedand nothing else. The files stay on disk, theignore rule from #108 now takes effect, and no history is rewritten. The diff
touches no path outside a
bin/directory.Why not rewrite develop instead
A rewrite would not achieve the goal and would break the superproject:
refs/pull/103/headon this repository, andGitHub's PR refs cannot be deleted by a maintainer. The fork branch holds them
too, and forks share object storage. Removing them for real is a GitHub
Support matter, not a force-push.
libs/openmethodis a submodule ofboostorg/boost, bumped by automationwithin minutes of each merge. Superproject
developcommits already pinopenmethod SHAs at and after the offending merge; orphaning those would make
git submodule updatefail at those commits, permanently.🤖 Generated with Claude Code