[brettheap]

Lane: openreposhape-1 (openRepoShape-1)
Claim: #530 (comment)

What

adopt-project.py check now reports two findings about the .gitattributes files of a source. execute refuses the same plans with the same codes before any leg repository exists. Both go through _entry_findings, with every other finding of check's (#168).

plan-nested-attributes, #530's line. It reports a .gitattributes that the plan keeps in the assembly root below the root, such as .github/.gitattributes or scripts/.gitattributes, when its rules outrank the root's line-ending rule for a pinned copy. The finding names the kept file, the pinned copies it reaches, and the exact line its own directory spells for each copy. For example:

FINDING plan-nested-attributes: the plan keeps `.github/.gitattributes` in the assembly root, and git reads it after the root's own `.gitattributes` for each path under `.github/`, so its rules outrank the root's line-ending rule for the pinned copy `.github/workflows/validate.yml`: a clone would check it out with CRLF line endings on every platform, Linux and macOS included, and the root's first `make bootstrap` would report shape-copy-drift on it, after `execute` had said `adoption verified`. Send `.github/.gitattributes` to a leg or `drop` it, or end `.github/.gitattributes` in the source with the line `/workflows/validate.yml text eol=lf`, commit, and re-run `plan`.

plan-attributes-reencoded, the D5(a) line. Lane 2 added this line to #530 at 2026-10-15T17:20:19Z, from the checklist triage Brett Heap approved at 16:49:38Z. It reports the source's own root .gitattributes, which the split appends #471's block to, when this machine's git add would store other bytes than the source's followed by the block, or would refuse them. For example, for a blob committed with CRLF under * text eol=lf:

FINDING plan-attributes-reencoded: the plan keeps the source's `.gitattributes` in the assembly root, where the split appends #471's block to it, and this machine's `git add` would store other bytes there than the source's followed by the block, as git does where its rules for the file make it text and the blob holds CRLF line endings, or where an `ident`, `working-tree-encoding` or `filter` rule reaches it. The verification would then report the source's `.gitattributes` as `adopt-lost`, in no leg and not in the root tree, after both legs exist. Commit the file in the source as git stores it (`git add --renormalize -- .gitattributes`, then commit), or change the rule git applies to it, and re-run `plan`.

Where git add refuses, the finding quotes git, for example (git said fatal: CRLF would be replaced by LF in .gitattributes) under this machine's core.safecrlf=true.

Some sources adopt as they did before:

• a source with no .gitattributes kept above a pinned copy;
• one whose root .gitattributes git add stores as written.

On #457, this closes the two lines marked → #530:

• the nested .gitattributes line (#457, comment);
• the CRLF root .gitattributes line (#457, comment).

The two riders marked → #530 there stay open (see "Not in this PR"):

• the .github -> ci link spelling 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;
• working-tree-encoding= and filter= over a pinned copy.

Why (repro on main)

A nested .gitattributes

#471 (PR #511, landed as 5ed3e5d) gives every pinned copy at the root one line-ending rule. Where the source keeps its own root .gitattributes, that rule is a /<copy> text eol=lf line in the block the split appends to that file. Where the source keeps none, it is the shape's own * text=auto eol=lf. Git reads attributes for a path from the .gitattributes of its own directory and of each directory above it, and a deeper file outranks a shallower one. So a kept nested file outranks that rule for every copy under it.

Measured on main at 2247dbf, with git 2.43.0 and git filter-repo 2.47.0:

• There were twelve real adoptions (plan, the nested file answered root, check, execute --local-remote-dir).
• Each was cloned three ways: as configured, with core.autocrlf=true, and with core.eol=crlf.
• For each clone I read git check-attr text eol, the bytes on disk of every pinned copy, and the first bootstrap.

kept nested file (root .gitattributes: * text=auto, unless noted)	copies with CRLF	clones that wrote CRLF	execute on main
.github/.gitattributes: *.yml eol=crlf	.github/workflows/validate.yml	all 3, Linux's default included	exit 0, adoption verified
the same, the source keeping no root .gitattributes	the same	all 3	exit 0, verified
.github/.gitattributes: * text=auto eol=crlf	the same	all 3	exit 0, verified
.github/.gitattributes: *.yml winfile, the root defining [attr]winfile text eol=crlf	the same	all 3	exit 0, verified
.github/.gitattributes: * !eol (with and without a root file)	the same	autocrlf and eol-crlf	exit 0, verified
scripts/.gitattributes: *.py eol=crlf, scripts/ kept in the root (with and without a root file)	the five scripts	all 3	exit 0, verified
.github/.gitattributes: * -text, * binary, * text, *.png binary	none	none	exit 0, verified

In every row with CRLF:

• check printed plan ok, and execute said adoption verified;
• the root's first make bootstrap reported shape-copy-drift on each copy reached, because validate-pins.py digests the bytes on disk (Templates ship a .gitattributes so a Windows clone of a scaffolded project passes its own gate (follow-up of #49) #51).

eol=crlf breaks the Linux and macOS clones too, not only Windows.

r530's review found the same defect through the old crlf spelling:

• A kept *.yml -crlf eol=crlf under a root * text=auto checked the copy out with CRLF in all three clones.
• * -crlf !eol did the same in the two clones that write CRLF.

* -text and * binary change no byte. git check-attr says text: unset there, but a checkout writes a file that is not text as its blob, and the copy's blob is LF (the materializer writes it with write_lf). All three clones held LF, and the bootstrap passed. So they are not findings.

The root's own .gitattributes, as git add stores it

The split appends #471's block to the source's root .gitattributes, the one file of the source's it writes into. So the split's git add -A -- . stores that file again, through git's rules for it:

• under text, or an eol (which says text), git stores CRLF as LF;
• ident collapses an expanded $Id: …$.

The verification (_land_the_eol_block) expects the source's blob followed by the block, finds neither, and reports the file lost after both legs exist.

Measured on main at 3f768a6, with git 2.43.0 and git filter-repo 2.47.0. Each source's root .gitattributes blob was committed byte for byte (hash-object --no-filters), then plan (nothing to answer), check, and execute --local-remote-dir:

root .gitattributes blob	check	execute on main 3f768a6
* text eol=lf, CRLF	0	1, FINDING adopt-lost: .gitattributes (3e48839d08fd) is in no leg, not in the root tree, and not listed as drop, both leg remotes made
* text eol=crlf, CRLF	0	1, the same adopt-lost, both leg remotes made
* eol=lf, CRLF	0	1, the same, both leg remotes made
# $Id: deadbeef $, then * ident	0	1, the same, both leg remotes made
* working-tree-encoding=UTF-16LE	0	2, REFUSED mounting the legs (git rm: the following file has local modifications), both leg remotes made
* text=auto, CRLF	0	0, adoption verified
* text eol=lf, LF	0	0, verified

At 2423eaa, where this question is still main's, these adopted and verified as well:

• * text=auto eol=lf, CRLF;
• * text eol=crlf, LF;
• CRLF with .gitattributes -text;
• CRLF under rules that name no .gitattributes (*.md text, *.png binary, and * text=auto with a CRLF *.md text eol=lf line).

text=auto leaves alone a file whose indexed blob already holds CRLF, which is why those adopt.

How

A nested .gitattributes

A finding, not a write. Brett Heap ruled at 2026-10-12T22:48Z that the root's .gitattributes is the one file of the source's that the split writes into, because no file beside it can reach the copies at the root. A nested file is not that case: the person can end it, in the source, with the lines the finding names, or keep it out of the root. Neither needs adopt to:

• write a second file of the source's;
• make a second exception to "by blob sha" in the verification;
• give update-shape.py --add a second block to extend.

The brief's option (b), appending lines to each nested file, would need all three, and Brett's ruling covers one file. So this is option (a): check finds it and execute refuses it before any leg.

Git is asked, never imitated. _AttributesProbe is a throwaway repository in the system's temporary directory, as _ask_git_branch makes one. Its work tree holds only these files, at the paths the split's tree will hold them:

• the root's .gitattributes as the split writes it (the source's bytes and 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, or the shape's own);
• the shape's shape/.gitattributes, where that goes beside the source's;
• the kept nested files.

git check-attr -z crlf text eol is then asked about each pinned copy where the split puts it. That place is read from _PlannedRoot's walks, which follow the root's symlinks as the materializer does. So patterns, macros, precedence and case folding are git's own. The probe reads no system or global attributes file (GIT_ATTR_NOSYSTEM=1, and -c core.attributesFile= set to an empty file), because another machine's clone has neither. A macro defined in a global attributes file here, such as [attr]keepbytes -text, would otherwise make a kept *.yml keepbytes eol=crlf look kept, though a clone on another machine writes that copy CRLF.

Nor does the rest of this machine's setup reach it. _probe_env gives git check-attr this process's environment with these changes:

• none of another repository's GIT_DIR and its kin, no GIT_ATTR_SOURCE, no GIT_CONFIG_PARAMETERS;
• no system config (GIT_CONFIG_NOSYSTEM=1) and an empty file as the global config (GIT_CONFIG_GLOBAL);
• attr.tree taken out of git's command scope (GIT_CONFIG_COUNT), whose other entries are kept in their order.

Measured with git 2.43:

• GIT_ATTR_SOURCE or attr.tree naming the empty tree made check-attr read no rule at all, which silenced the finding.
• GIT_ATTR_SOURCE=HEAD made the probe fail in its empty repository, and check printed REFUSED git-failed.

A test sets each of the four (the two GIT_ATTR_SOURCE values, and attr.tree in the global config and in the command scope) and shows the finding stands.

checked_out_as reads the answer as git's convert.c does for a checkout:

• text, else crlf (its old spelling, read only where text is unspecified), says whether the file is text, and one that is not is written as its blob;
• eol=lf keeps LF, and eol=crlf writes CRLF everywhere;
• with neither, only input keeps LF without asking core.autocrlf and core.eol.

One finding per cause.

• A copy is outranked when the root's own files keep it LF and the kept nested files, added, do not.
• Each kept file that, added to the root's own files alone, makes a checkout write such a copy with CRLF is named once (and only where no file alone does, each that changes what git says of the copy). It is named with every copy it reaches and its lines.
• A copy still outranked once those lines are in is named again by the next check, under the file that then decides it.
• A deeper kept file that restores LF leaves nothing to find, and one that alone keeps the copy LF is not named.
• A copy the root's own files already leave to the configuration is not a nested file's to answer for. A kept symlink can lead a copy where 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 does not reach it; that case is under "Known limits".
• A root .gitattributes that is a symlink is 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 follow-up, not this finding: its copies are asked against the block that follow-up asks a regular file to hold.
• A kept shape/.gitattributes where the shape writes its own is adopt-project.py check passes a plan that keeps the source's own shape/ in the root, and place() then writes the shape's collision copy onto it after both legs are pushed: a real shape/README.md is overwritten while execute prints "nothing was overwritten" and ends adopt-lost, and a shape/Makefile/ directory or a file named shape is a traceback #262's plan-root-blocks-shape-copy, and is not named again.

Both disks. The question is asked as a disk that keeps case does, and again as one that ignores it (core.ignorecase, and a .GitHub/.gitattributes read for .github/), as #262's findings are. A finding only the second makes says so with CASE_ASIDE, and says the copy is written CRLF "on such a disk, whatever git is set to".

A kept nested symlink counts. A checkout reads a .gitattributes from the index first, and there a symlink's blob is its target text. Measured with git 2.43: a kept .github/.gitattributes linking to *.yml eol=crlf checked the copy out with CRLF. A target that is a path names no attribute. For a symlink, the remedy says to replace it with a regular file.

The root's own .gitattributes

A finding, as the nested one is. The fix is the source's: commit the file as git stores it, or change the rule git applies to it. execute refuses it before any leg exists.

Asked of git as the split asks it. _stored_as_written makes a throwaway repository in the system's temporary directory and removes it afterwards.

• Its index holds the source's own blob at .gitattributes, as the assembly's checkout does (hash-object -w --no-filters, then update-index --cacheinfo). So git's check-in rules that read the index answer as they do there; text=auto leaves alone a blob that already holds CRLF.
• Its work tree holds what the verification expects at the root: the source's bytes followed by the block, from _root_attributes, the bytes the nested question uses too.
• git add is run there, and the oid it stages is compared with hash-object --no-filters of the same bytes.

The materializer appends the block to the checkout's bytes, and git's check-in undoes what its checkout did to line endings, an ident or an encoding. So the blob's own bytes get the same answer.

This machine's settings are read, unlike in the nested question. The split's git add runs here, with this machine's config and attributes: a global attributes file, core.autocrlf, core.safecrlf and a filter driver all count. So the question takes only _inherited_env, which _probe_env is now built on:

• no other repository's GIT_DIR and its kin;
• no GIT_ATTR_SOURCE or GIT_CONFIG_PARAMETERS;
• no command-scope attr.tree.

In the throwaway repository HEAD names nothing, and the empty tree, which any repository can name, holds no rule, so neither GIT_ATTR_SOURCE nor a command-scope attr.tree is passed. -c core.fsmonitor=false keeps a daemon from being started for it. Where git add refuses, the finding gives git's last line.

Asked only where the split writes into the file: where the plan keeps the source's root .gitattributes as a regular file. A source that keeps none gets the shape's own, and a symlink there is written through by nothing. Neither asks git anything.

The new code is one import, one section of adopt-project.py after _refuse_symlinks_checked_out_as_files, and one line in _entry_findings after _root_symlink_findings, with a clause in its docstring. The D5(a) line adds a second section after the first, a second line in _entry_findings after the first with its own clause, and _inherited_env, split out of _probe_env.

Nothing in scripts/shape_materialize.py, update-shape.py, the docs or the templates changes.

Byte for byte. At bbaa56a, I compared the split commits made by main and by this branch from the four sources that adopt (-text, binary, text, *.png binary):

• Every pinned copy, the root's .gitattributes, shape/.gitattributes and the kept .github/.gitattributes are identical.
• The only paths that differ record the leg commits, the shape's commit and tree digest, or the source's path, which differ between any two runs.

The D5(a) question prints nothing for a root .gitattributes that git add stores as written. All eight of its controls above, and a * filter= rule no driver here defines, adopt and verify end to end at ab7e8ef, as on main.

Tests

tests/test_adopt_nested_attributes.py, new, has 27 test functions and 79 cases: 18 and 58 for a nested .gitattributes, 9 and 21 for the root's own.

A nested .gitattributes:

• checked_out_as for 16 crlf/text/eol combinations, each checked against real checkouts with git 2.43 (as configured, with core.autocrlf=true and with core.eol=crlf);
• the finding for each cause in the first table above, and for r530's *.yml -crlf eol=crlf: its file, copies, lines and the words for where CRLF is written;
• execute's refusal before any leg (refused_before_any_leg, which needs no git filter-repo);
• a root .gitattributes that is a symlink, and a kept nested symlink read as its target;
• _outranking asked directly with a root that keeps the copy LF and one that does not;
• a kept shape/.gitattributes, which only adopt-project.py check passes a plan that keeps the source's own shape/ in the root, and place() then writes the shape's collision copy onto it after both legs are pushed: a real shape/README.md is overwritten while execute prints "nothing was overwritten" and ends adopt-lost, and a shape/Makefile/ directory or a file named shape is a traceback #262 names;
• nine controls that are no finding:
  • -text, binary and text;
  • -crlf with crlf=input, and crlf -text eol=crlf;
  • another path, and the finding's own remedy;
  • the file sent to a leg, and a deeper kept file that restores eol=lf;
• the naming of causes:
  • one file named per cause;
  • a file that alone keeps the copy LF is not named;
  • a cause two files make only together is still named;
  • each cause with its own lines;
• the case-folding aside and its words;
• this machine's own attributes not read (a global [attr]keepbytes -text macro);
• no tree this machine names steering the question (the four settings above);
• the spelling of a copy's line;
• nothing asked of git for a source with no kept file above a copy;
• with git filter-repo, the remedied source and a -text source are adopted and cloned three ways:
  • as configured, with core.autocrlf=true and with core.eol=crlf;
  • git check-attr eol says lf for every pinned copy, and no pinned copy holds CRLF on disk;
  • the source's own README is CRLF where the clone was asked for it (the control);
  • the first bootstrap passes.

The root's own .gitattributes:

• found: CRLF under * text eol=lf, * text eol=crlf, * eol=lf and * text, and an expanded $Id under * ident;
• six controls that are no finding:
  • CRLF under * text=auto and * text=auto eol=lf;
  • LF under * text eol=lf and * text eol=crlf;
  • CRLF its own rules leave alone (.gitattributes -text);
  • CRLF no rule names;
• * working-tree-encoding=UTF-16LE over the root's own file;
• execute's refusal before any leg;
• core.safecrlf=true in the command scope, which makes git refuse: the finding in git's words;
• this machine's global attributes file read for the split (.gitattributes text eol=lf over a CRLF blob whose own rules say nothing of it);
• GIT_ATTR_SOURCE (HEAD, the empty tree) and a command-scope attr.tree not steering it;
• nothing asked of git for a source with no root .gitattributes, or with a symlink there;
• with git filter-repo, the finding's way out taken (git add --renormalize, commit, plan again): check finds nothing, and execute verifies.

How every run below was made:

• /usr/bin/python3 -m pytest, with a stub gh first on PATH, a bogus GH_TOKEN and an empty GH_CONFIG_DIR;

• GIT_CONFIG_GLOBAL=/dev/null, and no GIT_ALLOW_PROTOCOL;

• each log names its head or tree and dirty 0, and ends in pytest's own exit code.

• Both modes at ab7e8ef (tree d21a7d9d), dirty 0, in a standalone clone of the commit. The targeted set is 72 files: grep -l -E 'adopt-project|adopt_project|\bADOPT\b' tests/*.py, which includes tests/conftest.py (no tests), tests/test_shape_doctor.py and tests/test_scaffold_leg_path_collisions.py. Each mode ran in 4 parallel chunks of whole files.

  mode	passed	skipped	failed	exit
  git-filter-repo 2.47.0 on PATH	5,780	13	0	0 in every chunk
  hidden (PATH=<stub gh>:/usr/local/bin:/usr/bin:/bin)	5,460	333	0	0 in every chunk

  Each mode collected the same 5,793 tests.

• On the merge with main 3f768a6 (siblings.py and family.py: make siblings asks about the family folder before it clones, clones each member on its tracking branch, and family.py siblings runs the holder's own copy (#543) #578, one commit past ci: run the test suite on Linux only #597's 654c476). git merge-tree --write-tree ab7e8efe 3f768a66 is clean, giving tree bddd1d1a. That tree was committed in a standalone clone (4f9dee1e), dirty 0. There the grep gives 73 files, because main added tests/test_adopt_shape_pin_and_work_dir.py. Both modes ran, 4 chunks each.

  mode	passed	skipped	failed	exit
  git-filter-repo on PATH	5,868	13	0	0 in every chunk
  hidden	5,547	334	0	0 in every chunk

• At 2423eaa, the fix round before the D5(a) line: the same set passed, 5,759 passed and 13 skipped, and 5,440 passed and 332 skipped. Its merge with 3f768a6 (tree a8e3916c, 73 files) passed too, 5,847 and 13, and 5,527 and 333. Every chunk exited 0.

3196d85d changes only three comments, which now cite #530's review, and the module passes there: 79 passed, 0 skipped, 0 failed with git filter-repo on PATH.

Revert table: each change reverted alone in adopt-project.py, and the new module run each time.

change reverted alone	new tests that fail (of 79)
R0, the whole PR (adopt-project.py as on main 2247dbf)	56. The 23 that pass hold on main too: the nine nested controls, the six root controls, the seven end-to-end cases and the shape/.gitattributes case.
Rprev, both later rounds (adopt-project.py as at bbaa56a)	26: the 12 of r530's fixes, and the 14 of D5(a)
Rd5, the D5(a) line whole (adopt-project.py as at 2423eaa)	14: every D5(a) test except the six controls and the end-to-end remedy
R1, the nested line in _entry_findings	20: all seven causes, the refusal, both symlink cases, case folding, the four naming tests, the isolation test, and the four tree settings
R2, checked_out_as: a copy that is not text kept	unspecified unset crlf => kept, unset unspecified crlf => kept, set unset crlf => kept, set unset native => kept, crlf-set-under-minus-text
R3, checked_out_as: input kept	input unspecified unspecified => kept, unspecified input unset => kept
R4, checked_out_as: text read before crlf	unset set crlf => everywhere, set unset crlf => kept, set unset native => kept, unset set unspecified => by config, crlf-unset-beside-the-roots-text, crlf-set-under-minus-text
R5, the source's own root lines under the block (macros)	a-macro-the-root-defines, and the 12 D5(a) tests that ask git about those lines
R6, a linked root asked as the block, not as no rules	the root symlink case
R7, the disk that ignores case	the case-folding aside
R7b, the fold-only words	the case-folding aside
R8, every kept file above an outranked copy named	test_only_a_file_that_changes_a_copy_is_named, test_a_file_that_alone_keeps_the_copy_lf_is_not_named, test_a_cause_two_files_make_only_together_is_still_named
R8a, a file named when it changes git's answer (as at bbaa56a)	test_a_file_that_alone_keeps_the_copy_lf_is_not_named
R8b, no fallback where only files together break a copy	test_a_cause_two_files_make_only_together_is_still_named
R9, the root's own files must keep the copy LF	the-root-leaves-it-crlf
R10, a kept shape/.gitattributes left to #262	the shape/.gitattributes case
R11, a kept nested symlink read	the nested symlink case
R12, a name no line can spell	a-name-a-line-cannot-spell
R13, no probe unless a kept file is above a copy	above-no-copy
R14, core.attributesFile set to an empty file	the isolation test
R15, GIT_ATTR_SOURCE not inherited	the two GIT_ATTR_SOURCE cases of each question (4)
R16, no system or global config for the nested question	attr-tree-in-the-global-config
R17, attr.tree taken out of the command scope	attr-tree-in-the-command-scope, for each question (2)
R18, the D5(a) line in _entry_findings	12: the five found, the encoding, the refusal, core.safecrlf, this machine's attributes, and the three tree settings
R19, the source's blob held in the probe's index	crlf-under-text-auto, crlf-under-text-auto-eol-lf
R20, this machine's attributes file read by the probe's git add	test_this_machines_own_attributes_are_read_for_the_split
R21, only _inherited_env given to the probe's git add	the three tree settings of the D5(a) question
R22, git add's refusal read	test_what_this_machines_git_add_refuses_is_found_in_gits_words
R23, a kept root symlink not asked about	a-root-attributes-symlink

The table was run at ab7e8ef in a standalone clone of the commit, so the worktree was never edited. The file was restored after each row, and its sha256 checked (86e5f2a8 before and after).

Windows

CI is Linux only since #597 (Brett Heap's estate-wide decision of 2026-10-15T16:54:43Z), so no Windows job runs these tests now. They are still written to hold there:

• The tests make no symlink on the disk. The symlinks are written into the tree with update-index --cacheinfo, so they need no privilege.
• Every path is legal on NTFS.
• Both probes write their files with write_bytes.
• The D5(a) tests commit the root .gitattributes byte for byte (hash-object --no-filters), so a checkout's newline translation does not change what they test.
• The nested finding is the same on a disk that ignores case, because its probe passes core.ignorecase explicitly and writes each file at the spelling it is asked under.

Before #597, at bbaa56a, the nested-file tests also passed (48 of 48) under a Windows newline emulation: a pytest plugin, kept outside the repository, that makes text-mode Path.write_text and text-mode stdin write \r\n.

Not in this PR

• Appending lines to a nested .gitattributes (the brief's option b): see How.
• update-shape.py apply --add writing a new copy under a directory where the project keeps a nested .gitattributes. The doctor does not read attributes either.
• The .github -> ci rider on 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, from Tracking: adopt-project.py, converting an existing repository in place #457: a pinned copy written through a kept directory link 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 the link's spelling (/.github/workflows/validate.yml text eol=lf), so the copy git tracks (ci/workflows/validate.yml) checks out by the source's own rules.
  • Left open because its fix is the block naming the path git tracks. That block is written in scripts/shape_materialize.py (eol_block_paths, _append_eol_block), recomputed by _land_the_eol_block, and extended by update-shape.py --add (extend_eol_block). This PR's questions only read it.
• The working-tree-encoding= and filter= rider on 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, from Tracking: adopt-project.py, converting an existing repository in place #457: such a rule over a pinned copy makes execute die at git add, after both legs exist.
  • Left open because this PR asks git about the one source file the split writes into. A pinned copy's bytes are the materializer's: the Makefile gets the adopt block, and copies land through the root's links and beside collisions.
  • The rule's checkout half cannot be asked here at all: a cloner's own filter driver, or a working-tree-encoding smudge on another machine.
  • A rule that reaches the root's own .gitattributes, such as * working-tree-encoding=UTF-16LE, is found by plan-attributes-reencoded.
  • ident changes no pinned copy today, because none holds $Id.
• Another kept file whose blob git add would re-encode (reported for Tracking: adopt-project.py, converting an existing repository in place #457's checklist). Measured at 2423eaa, under a root * text eol=lf:
  • A CRLF notes.txt, or a CRLF docs/.gitattributes, kept in the root: execute exits 1 with adopt-lost for that file, after both legs exist.
  • The same file sent to a leg: execute exits 2 with REFUSED mounting the legs, where git rm says the following file has local modifications.
  • Asking about every such path needs a checkout of the whole source in check.
• $GIT_DIR/info/attributes, which belongs to one clone.

Known limits

• A kept symlink can lead a copy where 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 does not reach it. The block names each copy by its pinned path, and a symlink the root keeps can lead a copy somewhere else.
  • Measured on main at 2247dbf: a source kept its own .gitattributes (* text=auto) and scripts -> tools in the root. The split's block said /scripts/bootstrap.py text eol=lf, but git tracks the copy at tools/bootstrap.py.
  • In a core.autocrlf=true clone, tools/bootstrap.py read text: auto, eol: unspecified and held CRLF, and bootstrap reported shape-copy-drift on the five scripts after adoption verified.
  • That is a limit of 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, with no nested file involved, so this finding does not name it. It is the same limit as the .github -> ci rider above.
• A copy only the case-folding disk reaches. When one kept file reaches some copies on both disks and more on the disk that ignores case, its finding is the first disk's. The extra copies are named once that finding's lines are in and check is run again.
• A remedy line for a name no plain line spells. A copy that a kept symlink leads to a name with a space or a glob character gets "a text eol=lf line that names <path>" instead of a line to paste, though git would read a C-style quoted pattern ("/ci files/validate.yml" text eol=lf) or a backslash-escaped one (/a\[1\]/x.yml text eol=lf).
• plan-attributes-reencoded is asked with this machine's settings. A filter driver, core.safecrlf or a global attributes file configured here counts, as it does for an execute run here; an execute on another machine can meet another answer. GIT_ATTR_SOURCE, an attr.tree in git's command scope and GIT_CONFIG_PARAMETERS are not passed to the question, though the split's own git add reads them; an attr.tree in the global or system config is passed, as the split reads it.

Closes #530

🤖 Generated with Claude Code

Summary by Sourcery

Detect and reject .gitattributes configurations that could cause pinned-copy line-ending drift or corrupt the source attributes during adoption.

Bug Fixes:

• Prevent adoption plans from silently producing line-ending drift or losing the source root .gitattributes during execution.

Enhancements:

• Add plan findings for nested .gitattributes files that override pinned-copy line-ending rules and for root .gitattributes files that git add would re-encode or reject.
• Refuse affected executions before creating any leg repositories and use Git attribute and staging behavior to determine findings.

Tests:

• Add comprehensive coverage for attribute precedence, symlinks, case handling, Git configuration isolation, re-encoding scenarios, early refusal, and end-to-end clone verification.

[sourcery-ai]

Sorry @brettheap, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 1 day and 4 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[sourcery-ai]

Reviewer's Guide

The PR adds two preflight findings to adopt-project.py: Git-accurate detection of nested .gitattributes rules that can override pinned-copy line endings, and detection of root .gitattributes content that the split's git add would rewrite or reject. Both findings are wired through the existing check/execute finding pipeline and backed by comprehensive isolation and end-to-end tests.

Sequence diagram for adoption preflight attribute validation

sequenceDiagram
    participant User
    participant Adopt as adopt-project.py
    participant Plan
    participant Probe as ThrowawayGitRepository
    participant Git
    participant Execute
    participant Legs as LegRepositories

    User->>Adopt: check
    Adopt->>Plan: Load plan and source tree
    Adopt->>Probe: Build planned .gitattributes layout
    Probe->>Git: check-attr -z crlf text eol
    Git-->>Probe: Attributes for pinned copies
    Probe-->>Adopt: Nested rule findings
    Adopt->>Probe: Stage source .gitattributes and run git add
    Probe->>Git: git add .gitattributes
    Git-->>Probe: Stored oid or refusal
    Probe-->>Adopt: Re-encoding finding
    Adopt-->>User: plan ok or FINDING

    User->>Execute: execute
    Execute->>Adopt: _entry_findings
    Adopt-->>Execute: Same findings
    alt Finding exists
        Execute-->>User: REFUSED before any leg
    else No finding
        Execute->>Legs: Create and mount leg repositories
        Legs-->>Execute: Adoption result
        Execute-->>User: adoption verified
    end

Loading

Flow diagram for preflight refusal before leg creation

flowchart TD
    Start[Load adoption plan] --> Findings[_entry_findings]
    Findings --> NestedCheck{Nested .gitattributes overrides pinned-copy rule?}
    NestedCheck -- Yes --> NestedFinding[Emit plan-nested-attributes]
    NestedCheck -- No --> RootCheck{Root .gitattributes would be rewritten or rejected by git add?}
    RootCheck -- Yes --> RootFinding[Emit plan-attributes-reencoded]
    RootCheck -- No --> Clear[No new attribute finding]
    NestedFinding --> Refuse[check reports finding; execute refuses]
    RootFinding --> Refuse
    Clear --> Existing[Continue existing preflight findings]
    Existing --> Legs{All findings clear?}
    Legs -- No --> Refuse
    Legs -- Yes --> Create[Create leg repositories]
    Create --> Verify[Materialize and verify adoption]

Loading

File-Level Changes

Change	Details	Files
Adds Git-backed detection for nested .gitattributes files whose rules override the root line-ending policy for pinned copies, and refuses affected plans before creating leg repositories.	Models the materialized assembly in a throwaway repository and uses git check-attr to evaluate precedence, macros, symlinks, case folding, and checkout behavior. Identifies affected pinned copies, attributes files, and remediation lines, including CRLF behavior and case-only findings. Integrates the finding into _entry_findings so check reports plan-nested-attributes and execute shares the same refusal path. Isolates inherited Git environment and configuration so unrelated repositories, attribute trees, and global/system attributes do not affect the nested-file probe.	adopt-project.py
Detects when staging the source root .gitattributes would re-encode or reject the bytes produced by appending the line-ending block.	Stages the original blob in a throwaway index and runs this machine's git add against the expected appended content. Reports plan-attributes-reencoded, including Git's refusal text, for line-ending conversion, ident, encoding, filter, and safe-crlf cases. Preserves the split's inherited machine-specific Git behavior while excluding unrelated repositories and attribute-tree sources. Refuses affected plans before any leg exists and provides renormalization or rule-change remediation.	adopt-project.py
Adds extensive unit, isolation, refusal, symlink, case-folding, and end-to-end coverage for both new plan findings.	Validates checkout semantics for legacy crlf, text, and eol combinations against Git behavior. Covers nested-file causes, precedence, macros, symlinks, copied paths, root/shape interactions, environment isolation, and no-probe controls. Covers root-file re-encoding, Git refusal messages, machine attributes, encoding rules, tree-source isolation, and non-applicable cases. Verifies refusals occur before leg creation and that remediated adoptions clone with LF-pinned copies and pass bootstrap.	tests/test_adopt_nested_attributes.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#530	Prevent adoption from reporting success when a kept nested .gitattributes overrides the root line-ending rule and causes a pinned copy to check out with CRLF.	✅

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud