adopt-project.py check: a kept or moved file other than .gitattributes whose blob git add would re-encode passes, and execute ends adopt-lost or dies mounting the legs after both legs are pushed #654

Lane: openreposhape-1 (openRepoShape-1)

check should find, before any leg exists, a kept or moved file other than the root's .gitattributes whose blob git add would re-encode, as #619 now does for .gitattributes itself. The issue opens with a one-page design, because finding these files means staging the whole source as the split does, which costs time on a large source.

From lane 1's triage of 2026-10-15, D5, approved by Brett Heap at 2026-10-16T11:21:17Z ("Approve all (Recommended)"). One pull request covers the lines below, after the design page.

Parent: #457. Milestone: v1.1.0.

Lands after: nothing.

Effort: L. Platform: all.

Lane openRepoShape-1 claims it at filing; see its CLAIMED comment.

Why this is P2. The precedent ranked this class P2 for .gitattributes itself (#530: its line is the second of #457's issuecomment-6172765796), and #619, which closed #530, now finds that case before any leg. On 7ba64f0, #619's _reencoded_attributes_findings is for the source's own root .gitattributes. Any other such file still passes check and fails after both legs:

• a CRLF notes.txt kept in the root under * text eol=lf ends adopt-lost;
• any file sent to a leg under a working-tree-encoding rule dies at "mounting the legs", where git rm refuses.

L1-09's writer measured both on 2423eaa, unchanged on ab7e8ef.

It opens with a one-page design of how check stages the whole source as the split does, and what that costs on a large source.

Lines

• L1-09 (P2): any other kept file whose blob git add would re-encode still fails after both legs. Kept in the root (a CRLF notes.txt or docs/.gitattributes under * text eol=lf) it ends adopt-lost; sent to a leg, git rm refuses at "mounting the legs" (* working-tree-encoding=UTF-16LE does that to every file bound for a leg). Asking needs a whole-source checkout in check. The line measured it on 2423eaa, unchanged on ab7e8ef. Not re-checked on main since adopt-project.py: check finds, and execute refuses before any leg, a kept nested .gitattributes that outranks the root's line-ending rule for a pinned copy, and a root .gitattributes that git add would re-encode (#530) #619 landed. (source)

Rides along (backlog; tick it here if the same change covers it)

• L1-11: two sentences about a symlinked .gitattributes are inexact: one in scripts/shape_materialize.py:937 and one in adopt-project.py: check finds, and execute refuses before any leg, a kept nested .gitattributes that outranks the root's line-ending rule for a pinned copy, and a root .gitattributes that git add would re-encode (#530) #619's finding. Wording only. First sentence: read on 396c0ff and read again on 7ba64f0 (:937). Second sentence: adopt-project.py: check finds, and execute refuses before any leg, a kept nested .gitattributes that outranks the root's line-ending rule for a pinned copy, and a root .gitattributes that git add would re-encode (#530) #619's finding, now on main; not re-read there. (source)
• L1-12: plan-attributes-reencoded says a root working-tree-encoding rule would end adopt-lost, but main dies earlier, at mounting the legs, and --renormalize changes nothing there. Wording only. Read on 706ace6, adopt-project.py: check finds, and execute refuses before any leg, a kept nested .gitattributes that outranks the root's line-ending rule for a pinned copy, and a root .gitattributes that git add would re-encode (#530) #619's head. Read again on 7ba64f0: _reencoded_attributes_finding still says the verification would report adopt-lost where a working-tree-encoding rule reaches the root's .gitattributes. (source)
• adopt-project.py: a nested .gitattributes setting eol or -text for a pinned copy outranks #471's root LF block, so Windows writes CRLF #530 rider, the link spelling: a pinned copy written through a root-kept symlinked directory (.github -> ci) is named in tests-windows never executes an adoption: git-filter-repo is not installed there, so the eight adopt suites skip and v1.0.0's "adopt works on Windows" is unverified #471's block by its link spelling, so that line governs nothing; check and execute exit 0, the clone writes the copy CRLF, and validate-pins.py exits 1 with shape-copy-drift. Measured at 1ce4f45. adopt-project.py: check finds, and execute refuses before any leg, a kept nested .gitattributes that outranks the root's line-ending rule for a pinned copy, and a root .gitattributes that git add would re-encode (#530) #619 closed adopt-project.py: a nested .gitattributes setting eol or -text for a pinned copy outranks #471's root LF block, so Windows writes CRLF #530 without it. (source)
• adopt-project.py: a nested .gitattributes setting eol or -text for a pinned copy outranks #471's root LF block, so Windows writes CRLF #530 rider, other rules: tests-windows never executes an adoption: git-filter-repo is not installed there, so the eight adopt suites skip and v1.0.0's "adopt works on Windows" is unverified #471's block settles line endings only, so a source filter= or working-tree-encoding= rule reaches a pinned copy; execute exits 2 at git add -A after both legs exist, and nothing is rolled back. Measured at 1ce4f45. adopt-project.py: check finds, and execute refuses before any leg, a kept nested .gitattributes that outranks the root's line-ending rule for a pinned copy, and a root .gitattributes that git add would re-encode (#530) #619 closed adopt-project.py: a nested .gitattributes setting eol or -text for a pinned copy outranks #471's root LF block, so Windows writes CRLF #530 without it. (source)

Each line above is a line of #457's checklist comment (issuecomment-6200110061 for L1-09, L1-11 and L1-12; issuecomment-6172765796 for the two #530 riders). Tick it there too when this closes. The two #530 riders start → #530 rider, open after #619 on #457 and are re-pointed to this issue.