When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.
Git attributes attach path-based metadata that changes how selected Git operations treat content, including text normalization, end-of-line conversion, diffs, merges, filters and archives. Mastery means separating repository content from working-tree presentation, proving which rule applies with git check-attr and changing policy without silently rewriting unrelated files. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.
The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.
Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.
Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.
Find your next learning step
Choose the route that matches the present difficulty. Use the complete index for a systematic course.
Build the model
Chapters 1-4 . Begin here, then continue after the learner can predict, verify and explain.
Use the core tools
Chapters 5-8 . Begin here, then continue after the learner can predict, verify and explain.
Handle boundaries
Chapters 9-12 . Begin here, then continue after the learner can predict, verify and explain.
Debug and verify
Chapters 13-16 . Begin here, then continue after the learner can predict, verify and explain.
Transfer with judgment
Chapters 17-20 . Begin here, then continue after the learner can predict, verify and explain.
Open the full chapter index . Jump to capstone practice . Use the How Studying Works hub . Read the official documentation
Complete chapter index
Chapters 1-4 . Build the model
Chapters 5-8 . Use the core tools
Chapters 9-12 . Handle boundaries
Chapters 13-16 . Debug and verify
Chapters 17-20 . Transfer with judgment
Attributes are selected by pathname patterns and consumed by particular Git features; they are not general shell flags or file permissions. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is reading .gitattributes as a command that immediately rewrites every file. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Name the path, resolved attribute and consuming Git operation separately.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.txt text
*.png binaryExplained result. Text files are marked for text handling and PNG files receive the binary macro when relevant operations inspect them. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Predict the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes are selected by pathname patterns and consumed by particular Git features; they are not general shell flags or file permissions.” Apply this procedure: Name the path, resolved attribute and consuming Git operation separately. The expected mechanism is: Text files are marked for text handling and PNG files receive the binary macro when relevant operations inspect them. For the coding project, add one near-miss that exposes reading .gitattributes as a command that immediately rewrites every file. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Contrast the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes are selected by pathname patterns and consumed by particular Git features; they are not general shell flags or file permissions.” Apply this procedure: Name the path, resolved attribute and consuming Git operation separately. The expected mechanism is: Text files are marked for text handling and PNG files receive the binary macro when relevant operations inspect them. For the group assignment, add one near-miss that exposes reading .gitattributes as a command that immediately rewrites every file. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: data folder. Stress-test the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes are selected by pathname patterns and consumed by particular Git features; they are not general shell flags or file permissions.” Apply this procedure: Name the path, resolved attribute and consuming Git operation separately. The expected mechanism is: Text files are marked for text handling and PNG files receive the binary macro when relevant operations inspect them. For the data folder, add one near-miss that exposes reading .gitattributes as a command that immediately rewrites every file. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: website project. Explain the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes are selected by pathname patterns and consumed by particular Git features; they are not general shell flags or file permissions.” Apply this procedure: Name the path, resolved attribute and consuming Git operation separately. The expected mechanism is: Text files are marked for text handling and PNG files receive the binary macro when relevant operations inspect them. For the website project, add one near-miss that exposes reading .gitattributes as a command that immediately rewrites every file. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers reading .gitattributes as a command that immediately rewrites every file.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Name the path, resolved attribute and consuming Git operation separately.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny documentation release with Markdown sources and files excluded from archives. Include one ordinary case, one boundary and one deliberate failure caused by reading .gitattributes as a command that immediately rewrites every file. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Attributes are selected by pathname patterns and consumed by particular Git features; they are not general shell flags or file permissions. It shows a trace, not only a final value. The ordinary case should demonstrate “Text files are marked for text handling and PNG files receive the binary macro when relevant operations inspect them.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Name the path, resolved attribute and consuming Git operation separately. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Git can read attributes from repository .gitattributes files, .git/info/attributes and configured system or global locations, with precedence depending on source and directory depth. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is editing one file while an overriding rule elsewhere remains active. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use git check-attr with –source where supported and inspect rules from closest to broadest scope.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
git check-attr --all -- path/to/file.txtExplained result. The output reveals the effective attributes for that path instead of relying on memory. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: data folder. Contrast the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git can read attributes from repository .gitattributes files, .git/info/attributes and configured system or global locations, with precedence depending on source and directory depth.” Apply this procedure: Use git check-attr with –source where supported and inspect rules from closest to broadest scope. The expected mechanism is: The output reveals the effective attributes for that path instead of relying on memory. For the data folder, add one near-miss that exposes editing one file while an overriding rule elsewhere remains active. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: website project. Stress-test the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git can read attributes from repository .gitattributes files, .git/info/attributes and configured system or global locations, with precedence depending on source and directory depth.” Apply this procedure: Use git check-attr with –source where supported and inspect rules from closest to broadest scope. The expected mechanism is: The output reveals the effective attributes for that path instead of relying on memory. For the website project, add one near-miss that exposes editing one file while an overriding rule elsewhere remains active. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science lab. Explain the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git can read attributes from repository .gitattributes files, .git/info/attributes and configured system or global locations, with precedence depending on source and directory depth.” Apply this procedure: Use git check-attr with –source where supported and inspect rules from closest to broadest scope. The expected mechanism is: The output reveals the effective attributes for that path instead of relying on memory. For the science lab, add one near-miss that exposes editing one file while an overriding rule elsewhere remains active. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Transfer the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git can read attributes from repository .gitattributes files, .git/info/attributes and configured system or global locations, with precedence depending on source and directory depth.” Apply this procedure: Use git check-attr with –source where supported and inspect rules from closest to broadest scope. The expected mechanism is: The output reveals the effective attributes for that path instead of relying on memory. For the documentation release, add one near-miss that exposes editing one file while an overriding rule elsewhere remains active. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers editing one file while an overriding rule elsewhere remains active.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use git check-attr with –source where supported and inspect rules from closest to broadest scope.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny template repository with placeholders transformed only by an explicit filter. Include one ordinary case, one boundary and one deliberate failure caused by editing one file while an overriding rule elsewhere remains active. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Git can read attributes from repository .gitattributes files, .git/info/attributes and configured system or global locations, with precedence depending on source and directory depth. It shows a trace, not only a final value. The ordinary case should demonstrate “The output reveals the effective attributes for that path instead of relying on memory.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use git check-attr with –source where supported and inspect rules from closest to broadest scope. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Attribute patterns resemble .gitignore patterns but negative patterns are forbidden and a directory pattern does not recursively match all descendants. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is copying a directory ignore rule and expecting recursive attribute coverage. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use path/** for descendants and test representative files at several depths.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
docs/** textExplained result. Files below docs receive text; a bare docs/ rule would not carry the same recursive meaning. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science lab. Stress-test the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attribute patterns resemble .gitignore patterns but negative patterns are forbidden and a directory pattern does not recursively match all descendants.” Apply this procedure: Use path/** for descendants and test representative files at several depths. The expected mechanism is: Files below docs receive text; a bare docs/ rule would not carry the same recursive meaning. For the science lab, add one near-miss that exposes copying a directory ignore rule and expecting recursive attribute coverage. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Explain the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attribute patterns resemble .gitignore patterns but negative patterns are forbidden and a directory pattern does not recursively match all descendants.” Apply this procedure: Use path/** for descendants and test representative files at several depths. The expected mechanism is: Files below docs receive text; a bare docs/ rule would not carry the same recursive meaning. For the documentation release, add one near-miss that exposes copying a directory ignore rule and expecting recursive attribute coverage. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: template repository. Transfer the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attribute patterns resemble .gitignore patterns but negative patterns are forbidden and a directory pattern does not recursively match all descendants.” Apply this procedure: Use path/** for descendants and test representative files at several depths. The expected mechanism is: Files below docs receive text; a bare docs/ rule would not carry the same recursive meaning. For the template repository, add one near-miss that exposes copying a directory ignore rule and expecting recursive attribute coverage. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: merge rehearsal. Predict the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attribute patterns resemble .gitignore patterns but negative patterns are forbidden and a directory pattern does not recursively match all descendants.” Apply this procedure: Use path/** for descendants and test representative files at several depths. The expected mechanism is: Files below docs receive text; a bare docs/ rule would not carry the same recursive meaning. For the merge rehearsal, add one near-miss that exposes copying a directory ignore rule and expecting recursive attribute coverage. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers copying a directory ignore rule and expecting recursive attribute coverage.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use path/** for descendants and test representative files at several depths.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny merge rehearsal with structured files needing a documented merge policy. Include one ordinary case, one boundary and one deliberate failure caused by copying a directory ignore rule and expecting recursive attribute coverage. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Attribute patterns resemble .gitignore patterns but negative patterns are forbidden and a directory pattern does not recursively match all descendants. It shows a trace, not only a final value. The ordinary case should demonstrate “Files below docs receive text; a bare docs/ rule would not carry the same recursive meaning.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use path/** for descendants and test representative files at several depths. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
An attribute can be Set, Unset, assigned a string value or left Unspecified, and consumers interpret those states according to their own contracts. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is treating false, -attr and absence as interchangeable. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Ask git check-attr for the exact attribute and record the four possible states.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.dat -text
*.md diff=markdownExplained result. dat files have text Unset; Markdown files assign the value markdown to diff. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: template repository. Explain the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An attribute can be Set, Unset, assigned a string value or left Unspecified, and consumers interpret those states according to their own contracts.” Apply this procedure: Ask git check-attr for the exact attribute and record the four possible states. The expected mechanism is: dat files have text Unset; Markdown files assign the value markdown to diff. For the template repository, add one near-miss that exposes treating false, -attr and absence as interchangeable. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: merge rehearsal. Transfer the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An attribute can be Set, Unset, assigned a string value or left Unspecified, and consumers interpret those states according to their own contracts.” Apply this procedure: Ask git check-attr for the exact attribute and record the four possible states. The expected mechanism is: dat files have text Unset; Markdown files assign the value markdown to diff. For the merge rehearsal, add one near-miss that exposes treating false, -attr and absence as interchangeable. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Predict the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An attribute can be Set, Unset, assigned a string value or left Unspecified, and consumers interpret those states according to their own contracts.” Apply this procedure: Ask git check-attr for the exact attribute and record the four possible states. The expected mechanism is: dat files have text Unset; Markdown files assign the value markdown to diff. For the coding project, add one near-miss that exposes treating false, -attr and absence as interchangeable. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Contrast the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An attribute can be Set, Unset, assigned a string value or left Unspecified, and consumers interpret those states according to their own contracts.” Apply this procedure: Ask git check-attr for the exact attribute and record the four possible states. The expected mechanism is: dat files have text Unset; Markdown files assign the value markdown to diff. For the group assignment, add one near-miss that exposes treating false, -attr and absence as interchangeable. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers treating false, -attr and absence as interchangeable.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Ask git check-attr for the exact attribute and record the four possible states.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny coding project with source files, generated reports and binary screenshots. Include one ordinary case, one boundary and one deliberate failure caused by treating false, -attr and absence as interchangeable. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: An attribute can be Set, Unset, assigned a string value or left Unspecified, and consumers interpret those states according to their own contracts. It shows a trace, not only a final value. The ordinary case should demonstrate “dat files have text Unset; Markdown files assign the value markdown to diff.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Ask git check-attr for the exact attribute and record the four possible states. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The built-in binary attribute macro expands to -diff -merge -text, expressing a conventional treatment for binary content. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming binary detects file type by itself or applies every possible binary policy. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Verify the path rule and inspect the expanded effective attributes.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.jpg binaryExplained result. Matching JPEG paths are treated as non-text for the relevant diff, merge and text-normalisation decisions. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Transfer the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The built-in binary attribute macro expands to -diff -merge -text, expressing a conventional treatment for binary content.” Apply this procedure: Verify the path rule and inspect the expanded effective attributes. The expected mechanism is: Matching JPEG paths are treated as non-text for the relevant diff, merge and text-normalisation decisions. For the coding project, add one near-miss that exposes assuming binary detects file type by itself or applies every possible binary policy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Predict the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The built-in binary attribute macro expands to -diff -merge -text, expressing a conventional treatment for binary content.” Apply this procedure: Verify the path rule and inspect the expanded effective attributes. The expected mechanism is: Matching JPEG paths are treated as non-text for the relevant diff, merge and text-normalisation decisions. For the group assignment, add one near-miss that exposes assuming binary detects file type by itself or applies every possible binary policy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: data folder. Contrast the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The built-in binary attribute macro expands to -diff -merge -text, expressing a conventional treatment for binary content.” Apply this procedure: Verify the path rule and inspect the expanded effective attributes. The expected mechanism is: Matching JPEG paths are treated as non-text for the relevant diff, merge and text-normalisation decisions. For the data folder, add one near-miss that exposes assuming binary detects file type by itself or applies every possible binary policy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: website project. Stress-test the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The built-in binary attribute macro expands to -diff -merge -text, expressing a conventional treatment for binary content.” Apply this procedure: Verify the path rule and inspect the expanded effective attributes. The expected mechanism is: Matching JPEG paths are treated as non-text for the relevant diff, merge and text-normalisation decisions. For the website project, add one near-miss that exposes assuming binary detects file type by itself or applies every possible binary policy. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming binary detects file type by itself or applies every possible binary policy.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Verify the path rule and inspect the expanded effective attributes.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny group assignment with notes edited on Windows, macOS and Linux. Include one ordinary case, one boundary and one deliberate failure caused by assuming binary detects file type by itself or applies every possible binary policy. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The built-in binary attribute macro expands to -diff -merge -text, expressing a conventional treatment for binary content. It shows a trace, not only a final value. The ordinary case should demonstrate “Matching JPEG paths are treated as non-text for the relevant diff, merge and text-normalisation decisions.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Verify the path rule and inspect the expanded effective attributes. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
For tracked text, Git can store a normalized representation in the index while checkout converts it for the working tree according to attributes and configuration. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is thinking autocrlf or eol merely changes what an editor displays. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Trace bytes from working tree to index on add and from index to working tree on checkout.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.txt text eol=lfExplained result. Matching files are normalized as text and checked out with LF line endings. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: data folder. Predict the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “For tracked text, Git can store a normalized representation in the index while checkout converts it for the working tree according to attributes and configuration.” Apply this procedure: Trace bytes from working tree to index on add and from index to working tree on checkout. The expected mechanism is: Matching files are normalized as text and checked out with LF line endings. For the data folder, add one near-miss that exposes thinking autocrlf or eol merely changes what an editor displays. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: website project. Contrast the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “For tracked text, Git can store a normalized representation in the index while checkout converts it for the working tree according to attributes and configuration.” Apply this procedure: Trace bytes from working tree to index on add and from index to working tree on checkout. The expected mechanism is: Matching files are normalized as text and checked out with LF line endings. For the website project, add one near-miss that exposes thinking autocrlf or eol merely changes what an editor displays. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science lab. Stress-test the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “For tracked text, Git can store a normalized representation in the index while checkout converts it for the working tree according to attributes and configuration.” Apply this procedure: Trace bytes from working tree to index on add and from index to working tree on checkout. The expected mechanism is: Matching files are normalized as text and checked out with LF line endings. For the science lab, add one near-miss that exposes thinking autocrlf or eol merely changes what an editor displays. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Explain the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “For tracked text, Git can store a normalized representation in the index while checkout converts it for the working tree according to attributes and configuration.” Apply this procedure: Trace bytes from working tree to index on add and from index to working tree on checkout. The expected mechanism is: Matching files are normalized as text and checked out with LF line endings. For the documentation release, add one near-miss that exposes thinking autocrlf or eol merely changes what an editor displays. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers thinking autocrlf or eol merely changes what an editor displays.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Trace bytes from working tree to index on add and from index to working tree on checkout.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny data folder with CSV inputs, large exports and compressed archives. Include one ordinary case, one boundary and one deliberate failure caused by thinking autocrlf or eol merely changes what an editor displays. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: For tracked text, Git can store a normalized representation in the index while checkout converts it for the working tree according to attributes and configuration. It shows a trace, not only a final value. The ordinary case should demonstrate “Matching files are normalized as text and checked out with LF line endings.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Trace bytes from working tree to index on add and from index to working tree on checkout. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
text=auto lets Git decide whether content appears text-like for normalization, while explicit text or -text states override that automatic judgment. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using auto as a guarantee for every unusual file format. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
* text=autoExplained result. Git automatically decides text normalization for paths not governed by a more specific rule. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science lab. Contrast the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “text=auto lets Git decide whether content appears text-like for normalization, while explicit text or -text states override that automatic judgment.” Apply this procedure: Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics. The expected mechanism is: Git automatically decides text normalization for paths not governed by a more specific rule. For the science lab, add one near-miss that exposes using auto as a guarantee for every unusual file format. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Stress-test the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “text=auto lets Git decide whether content appears text-like for normalization, while explicit text or -text states override that automatic judgment.” Apply this procedure: Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics. The expected mechanism is: Git automatically decides text normalization for paths not governed by a more specific rule. For the documentation release, add one near-miss that exposes using auto as a guarantee for every unusual file format. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: template repository. Explain the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “text=auto lets Git decide whether content appears text-like for normalization, while explicit text or -text states override that automatic judgment.” Apply this procedure: Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics. The expected mechanism is: Git automatically decides text normalization for paths not governed by a more specific rule. For the template repository, add one near-miss that exposes using auto as a guarantee for every unusual file format. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: merge rehearsal. Transfer the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “text=auto lets Git decide whether content appears text-like for normalization, while explicit text or -text states override that automatic judgment.” Apply this procedure: Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics. The expected mechanism is: Git automatically decides text normalization for paths not governed by a more specific rule. For the merge rehearsal, add one near-miss that exposes using auto as a guarantee for every unusual file format. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using auto as a guarantee for every unusual file format.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny website project with HTML, CSS, minified assets and media files. Include one ordinary case, one boundary and one deliberate failure caused by using auto as a guarantee for every unusual file format. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: text=auto lets Git decide whether content appears text-like for normalization, while explicit text or -text states override that automatic judgment. It shows a trace, not only a final value. The ordinary case should demonstrate “Git automatically decides text normalization for paths not governed by a more specific rule.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The eol attribute requests lf or crlf line endings in the working tree for paths treated as text, while the index remains normalized. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is adding eol to content still considered binary and expecting conversion. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Confirm text status first, then inspect index and worktree bytes independently.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.bat text eol=crlf
*.sh text eol=lfExplained result. Batch files check out with CRLF and shell scripts with LF while normalized repository content uses LF. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: template repository. Stress-test the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The eol attribute requests lf or crlf line endings in the working tree for paths treated as text, while the index remains normalized.” Apply this procedure: Confirm text status first, then inspect index and worktree bytes independently. The expected mechanism is: Batch files check out with CRLF and shell scripts with LF while normalized repository content uses LF. For the template repository, add one near-miss that exposes adding eol to content still considered binary and expecting conversion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: merge rehearsal. Explain the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The eol attribute requests lf or crlf line endings in the working tree for paths treated as text, while the index remains normalized.” Apply this procedure: Confirm text status first, then inspect index and worktree bytes independently. The expected mechanism is: Batch files check out with CRLF and shell scripts with LF while normalized repository content uses LF. For the merge rehearsal, add one near-miss that exposes adding eol to content still considered binary and expecting conversion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Transfer the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The eol attribute requests lf or crlf line endings in the working tree for paths treated as text, while the index remains normalized.” Apply this procedure: Confirm text status first, then inspect index and worktree bytes independently. The expected mechanism is: Batch files check out with CRLF and shell scripts with LF while normalized repository content uses LF. For the coding project, add one near-miss that exposes adding eol to content still considered binary and expecting conversion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Predict the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The eol attribute requests lf or crlf line endings in the working tree for paths treated as text, while the index remains normalized.” Apply this procedure: Confirm text status first, then inspect index and worktree bytes independently. The expected mechanism is: Batch files check out with CRLF and shell scripts with LF while normalized repository content uses LF. For the group assignment, add one near-miss that exposes adding eol to content still considered binary and expecting conversion. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers adding eol to content still considered binary and expecting conversion.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Confirm text status first, then inspect index and worktree bytes independently.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny science lab with plain-text observations and instrument binaries. Include one ordinary case, one boundary and one deliberate failure caused by adding eol to content still considered binary and expecting conversion. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The eol attribute requests lf or crlf line endings in the working tree for paths treated as text, while the index remains normalized. It shows a trace, not only a final value. The ordinary case should demonstrate “Batch files check out with CRLF and shell scripts with LF while normalized repository content uses LF.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Confirm text status first, then inspect index and worktree bytes independently. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
After changing text attributes, git add –renormalize can apply the new clean conversion to tracked paths, producing a reviewable index change. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is changing .gitattributes and assuming historical index entries update themselves. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Commit policy separately when useful, renormalize on a clean branch and inspect the entire staged diff.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
git add --renormalize .
git diff --cached --checkExplained result. Tracked content is reconsidered under current rules, and the staged result is reviewed before commit. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Explain the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After changing text attributes, git add –renormalize can apply the new clean conversion to tracked paths, producing a reviewable index change.” Apply this procedure: Commit policy separately when useful, renormalize on a clean branch and inspect the entire staged diff. The expected mechanism is: Tracked content is reconsidered under current rules, and the staged result is reviewed before commit. For the coding project, add one near-miss that exposes changing .gitattributes and assuming historical index entries update themselves. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Transfer the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After changing text attributes, git add –renormalize can apply the new clean conversion to tracked paths, producing a reviewable index change.” Apply this procedure: Commit policy separately when useful, renormalize on a clean branch and inspect the entire staged diff. The expected mechanism is: Tracked content is reconsidered under current rules, and the staged result is reviewed before commit. For the group assignment, add one near-miss that exposes changing .gitattributes and assuming historical index entries update themselves. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: data folder. Predict the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After changing text attributes, git add –renormalize can apply the new clean conversion to tracked paths, producing a reviewable index change.” Apply this procedure: Commit policy separately when useful, renormalize on a clean branch and inspect the entire staged diff. The expected mechanism is: Tracked content is reconsidered under current rules, and the staged result is reviewed before commit. For the data folder, add one near-miss that exposes changing .gitattributes and assuming historical index entries update themselves. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: website project. Contrast the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After changing text attributes, git add –renormalize can apply the new clean conversion to tracked paths, producing a reviewable index change.” Apply this procedure: Commit policy separately when useful, renormalize on a clean branch and inspect the entire staged diff. The expected mechanism is: Tracked content is reconsidered under current rules, and the staged result is reviewed before commit. For the website project, add one near-miss that exposes changing .gitattributes and assuming historical index entries update themselves. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers changing .gitattributes and assuming historical index entries update themselves.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Commit policy separately when useful, renormalize on a clean branch and inspect the entire staged diff.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny documentation release with Markdown sources and files excluded from archives. Include one ordinary case, one boundary and one deliberate failure caused by changing .gitattributes and assuming historical index entries update themselves. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: After changing text attributes, git add –renormalize can apply the new clean conversion to tracked paths, producing a reviewable index change. It shows a trace, not only a final value. The ordinary case should demonstrate “Tracked content is reconsidered under current rules, and the staged result is reviewed before commit.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Commit policy separately when useful, renormalize on a clean branch and inspect the entire staged diff. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
An EOL migration should freeze unrelated edits, establish one policy, renormalize once and let each collaborator refresh clean worktrees. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is mixing feature changes with a repository-wide normalization commit. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Create a clean migration branch, communicate timing and verify clones on two platforms.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
git status --short
git add --renormalize .Explained result. A clean starting state makes changed lines attributable to policy rather than hidden personal edits. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: data folder. Transfer the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An EOL migration should freeze unrelated edits, establish one policy, renormalize once and let each collaborator refresh clean worktrees.” Apply this procedure: Create a clean migration branch, communicate timing and verify clones on two platforms. The expected mechanism is: A clean starting state makes changed lines attributable to policy rather than hidden personal edits. For the data folder, add one near-miss that exposes mixing feature changes with a repository-wide normalization commit. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: website project. Predict the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An EOL migration should freeze unrelated edits, establish one policy, renormalize once and let each collaborator refresh clean worktrees.” Apply this procedure: Create a clean migration branch, communicate timing and verify clones on two platforms. The expected mechanism is: A clean starting state makes changed lines attributable to policy rather than hidden personal edits. For the website project, add one near-miss that exposes mixing feature changes with a repository-wide normalization commit. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science lab. Contrast the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An EOL migration should freeze unrelated edits, establish one policy, renormalize once and let each collaborator refresh clean worktrees.” Apply this procedure: Create a clean migration branch, communicate timing and verify clones on two platforms. The expected mechanism is: A clean starting state makes changed lines attributable to policy rather than hidden personal edits. For the science lab, add one near-miss that exposes mixing feature changes with a repository-wide normalization commit. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Stress-test the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “An EOL migration should freeze unrelated edits, establish one policy, renormalize once and let each collaborator refresh clean worktrees.” Apply this procedure: Create a clean migration branch, communicate timing and verify clones on two platforms. The expected mechanism is: A clean starting state makes changed lines attributable to policy rather than hidden personal edits. For the documentation release, add one near-miss that exposes mixing feature changes with a repository-wide normalization commit. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers mixing feature changes with a repository-wide normalization commit.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Create a clean migration branch, communicate timing and verify clones on two platforms.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny template repository with placeholders transformed only by an explicit filter. Include one ordinary case, one boundary and one deliberate failure caused by mixing feature changes with a repository-wide normalization commit. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: An EOL migration should freeze unrelated edits, establish one policy, renormalize once and let each collaborator refresh clean worktrees. It shows a trace, not only a final value. The ordinary case should demonstrate “A clean starting state makes changed lines attributable to policy rather than hidden personal edits.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Create a clean migration branch, communicate timing and verify clones on two platforms. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The diff attribute can force text or binary treatment or name a custom diff driver for specialised presentation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is believing a custom display diff changes stored content or merge meaning automatically. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Separate storage bytes, displayed diff and merge policy, then test each command independently.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.ipynb diff=jupyternotebookExplained result. The path names a configured diff driver; without the corresponding configuration, the attribute alone does not invent a converter. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science lab. Predict the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The diff attribute can force text or binary treatment or name a custom diff driver for specialised presentation.” Apply this procedure: Separate storage bytes, displayed diff and merge policy, then test each command independently. The expected mechanism is: The path names a configured diff driver; without the corresponding configuration, the attribute alone does not invent a converter. For the science lab, add one near-miss that exposes believing a custom display diff changes stored content or merge meaning automatically. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Contrast the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The diff attribute can force text or binary treatment or name a custom diff driver for specialised presentation.” Apply this procedure: Separate storage bytes, displayed diff and merge policy, then test each command independently. The expected mechanism is: The path names a configured diff driver; without the corresponding configuration, the attribute alone does not invent a converter. For the documentation release, add one near-miss that exposes believing a custom display diff changes stored content or merge meaning automatically. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: template repository. Stress-test the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The diff attribute can force text or binary treatment or name a custom diff driver for specialised presentation.” Apply this procedure: Separate storage bytes, displayed diff and merge policy, then test each command independently. The expected mechanism is: The path names a configured diff driver; without the corresponding configuration, the attribute alone does not invent a converter. For the template repository, add one near-miss that exposes believing a custom display diff changes stored content or merge meaning automatically. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: merge rehearsal. Explain the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The diff attribute can force text or binary treatment or name a custom diff driver for specialised presentation.” Apply this procedure: Separate storage bytes, displayed diff and merge policy, then test each command independently. The expected mechanism is: The path names a configured diff driver; without the corresponding configuration, the attribute alone does not invent a converter. For the merge rehearsal, add one near-miss that exposes believing a custom display diff changes stored content or merge meaning automatically. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers believing a custom display diff changes stored content or merge meaning automatically.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Separate storage bytes, displayed diff and merge policy, then test each command independently.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny merge rehearsal with structured files needing a documented merge policy. Include one ordinary case, one boundary and one deliberate failure caused by believing a custom display diff changes stored content or merge meaning automatically. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The diff attribute can force text or binary treatment or name a custom diff driver for specialised presentation. It shows a trace, not only a final value. The ordinary case should demonstrate “The path names a configured diff driver; without the corresponding configuration, the attribute alone does not invent a converter.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Separate storage bytes, displayed diff and merge policy, then test each command independently. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
A diff driver can use textconv to transform binary or structured content into a human-readable comparison, with security and reproducibility implications. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is running an untrusted converter merely because a repository names a driver. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Configure trusted commands locally, test failures and remember textconv output is for viewing rather than patching.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
[diff "pdf"]
textconv = pdftotextExplained result. When locally configured and trusted, PDF paths assigned diff=pdf can be compared through extracted text. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: template repository. Contrast the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A diff driver can use textconv to transform binary or structured content into a human-readable comparison, with security and reproducibility implications.” Apply this procedure: Configure trusted commands locally, test failures and remember textconv output is for viewing rather than patching. The expected mechanism is: When locally configured and trusted, PDF paths assigned diff=pdf can be compared through extracted text. For the template repository, add one near-miss that exposes running an untrusted converter merely because a repository names a driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: merge rehearsal. Stress-test the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A diff driver can use textconv to transform binary or structured content into a human-readable comparison, with security and reproducibility implications.” Apply this procedure: Configure trusted commands locally, test failures and remember textconv output is for viewing rather than patching. The expected mechanism is: When locally configured and trusted, PDF paths assigned diff=pdf can be compared through extracted text. For the merge rehearsal, add one near-miss that exposes running an untrusted converter merely because a repository names a driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Explain the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A diff driver can use textconv to transform binary or structured content into a human-readable comparison, with security and reproducibility implications.” Apply this procedure: Configure trusted commands locally, test failures and remember textconv output is for viewing rather than patching. The expected mechanism is: When locally configured and trusted, PDF paths assigned diff=pdf can be compared through extracted text. For the coding project, add one near-miss that exposes running an untrusted converter merely because a repository names a driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Transfer the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A diff driver can use textconv to transform binary or structured content into a human-readable comparison, with security and reproducibility implications.” Apply this procedure: Configure trusted commands locally, test failures and remember textconv output is for viewing rather than patching. The expected mechanism is: When locally configured and trusted, PDF paths assigned diff=pdf can be compared through extracted text. For the group assignment, add one near-miss that exposes running an untrusted converter merely because a repository names a driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers running an untrusted converter merely because a repository names a driver.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Configure trusted commands locally, test failures and remember textconv output is for viewing rather than patching.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny coding project with source files, generated reports and binary screenshots. Include one ordinary case, one boundary and one deliberate failure caused by running an untrusted converter merely because a repository names a driver. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A diff driver can use textconv to transform binary or structured content into a human-readable comparison, with security and reproducibility implications. It shows a trace, not only a final value. The ordinary case should demonstrate “When locally configured and trusted, PDF paths assigned diff=pdf can be compared through extracted text.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Configure trusted commands locally, test failures and remember textconv output is for viewing rather than patching. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Diff drivers can define word regexes and function-name patterns that improve human review without changing file content. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is making a complex regex that drops punctuation from meaningful review. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use fixtures containing punctuation and headings, then compare ordinary and word diff output.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
[diff "markdown"]
xfuncname = "^#{1,6} "Explained result. Markdown diff hunks can show nearby heading lines as context when the driver is selected. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Stress-test the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Diff drivers can define word regexes and function-name patterns that improve human review without changing file content.” Apply this procedure: Use fixtures containing punctuation and headings, then compare ordinary and word diff output. The expected mechanism is: Markdown diff hunks can show nearby heading lines as context when the driver is selected. For the coding project, add one near-miss that exposes making a complex regex that drops punctuation from meaningful review. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Explain the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Diff drivers can define word regexes and function-name patterns that improve human review without changing file content.” Apply this procedure: Use fixtures containing punctuation and headings, then compare ordinary and word diff output. The expected mechanism is: Markdown diff hunks can show nearby heading lines as context when the driver is selected. For the group assignment, add one near-miss that exposes making a complex regex that drops punctuation from meaningful review. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: data folder. Transfer the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Diff drivers can define word regexes and function-name patterns that improve human review without changing file content.” Apply this procedure: Use fixtures containing punctuation and headings, then compare ordinary and word diff output. The expected mechanism is: Markdown diff hunks can show nearby heading lines as context when the driver is selected. For the data folder, add one near-miss that exposes making a complex regex that drops punctuation from meaningful review. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: website project. Predict the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Diff drivers can define word regexes and function-name patterns that improve human review without changing file content.” Apply this procedure: Use fixtures containing punctuation and headings, then compare ordinary and word diff output. The expected mechanism is: Markdown diff hunks can show nearby heading lines as context when the driver is selected. For the website project, add one near-miss that exposes making a complex regex that drops punctuation from meaningful review. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers making a complex regex that drops punctuation from meaningful review.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use fixtures containing punctuation and headings, then compare ordinary and word diff output.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny group assignment with notes edited on Windows, macOS and Linux. Include one ordinary case, one boundary and one deliberate failure caused by making a complex regex that drops punctuation from meaningful review. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Diff drivers can define word regexes and function-name patterns that improve human review without changing file content. It shows a trace, not only a final value. The ordinary case should demonstrate “Markdown diff hunks can show nearby heading lines as context when the driver is selected.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use fixtures containing punctuation and headings, then compare ordinary and word diff output. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The merge attribute can select normal text merging, binary-style conflict handling or a named merge driver. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using merge=ours to mean keep our whole file without understanding the configured driver. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Rehearse conflicting branches in a disposable repository and inspect stage entries plus final content.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
generated.lock merge=binaryExplained result. A conflicting change to that path is not line-merged as ordinary text; resolution still requires deliberate review. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: data folder. Explain the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The merge attribute can select normal text merging, binary-style conflict handling or a named merge driver.” Apply this procedure: Rehearse conflicting branches in a disposable repository and inspect stage entries plus final content. The expected mechanism is: A conflicting change to that path is not line-merged as ordinary text; resolution still requires deliberate review. For the data folder, add one near-miss that exposes using merge=ours to mean keep our whole file without understanding the configured driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: website project. Transfer the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The merge attribute can select normal text merging, binary-style conflict handling or a named merge driver.” Apply this procedure: Rehearse conflicting branches in a disposable repository and inspect stage entries plus final content. The expected mechanism is: A conflicting change to that path is not line-merged as ordinary text; resolution still requires deliberate review. For the website project, add one near-miss that exposes using merge=ours to mean keep our whole file without understanding the configured driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science lab. Predict the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The merge attribute can select normal text merging, binary-style conflict handling or a named merge driver.” Apply this procedure: Rehearse conflicting branches in a disposable repository and inspect stage entries plus final content. The expected mechanism is: A conflicting change to that path is not line-merged as ordinary text; resolution still requires deliberate review. For the science lab, add one near-miss that exposes using merge=ours to mean keep our whole file without understanding the configured driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Contrast the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The merge attribute can select normal text merging, binary-style conflict handling or a named merge driver.” Apply this procedure: Rehearse conflicting branches in a disposable repository and inspect stage entries plus final content. The expected mechanism is: A conflicting change to that path is not line-merged as ordinary text; resolution still requires deliberate review. For the documentation release, add one near-miss that exposes using merge=ours to mean keep our whole file without understanding the configured driver. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using merge=ours to mean keep our whole file without understanding the configured driver.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Rehearse conflicting branches in a disposable repository and inspect stage entries plus final content.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny data folder with CSV inputs, large exports and compressed archives. Include one ordinary case, one boundary and one deliberate failure caused by using merge=ours to mean keep our whole file without understanding the configured driver. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The merge attribute can select normal text merging, binary-style conflict handling or a named merge driver. It shows a trace, not only a final value. The ordinary case should demonstrate “A conflicting change to that path is not line-merged as ordinary text; resolution still requires deliberate review.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Rehearse conflicting branches in a disposable repository and inspect stage entries plus final content. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
A named merge driver requires configuration that defines its command, markers and recursive behaviour; the attribute only selects the name. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is committing a driver name and assuming every clone has a safe implementation. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Document setup, fail clearly when absent and include a reproducible conflict test.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.notes merge=notes
[merge "notes"]
driver = notes-merge %O %A %BExplained result. The attribute routes matching conflicts to a locally configured notes driver whose command must be trusted and available. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science lab. Transfer the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A named merge driver requires configuration that defines its command, markers and recursive behaviour; the attribute only selects the name.” Apply this procedure: Document setup, fail clearly when absent and include a reproducible conflict test. The expected mechanism is: The attribute routes matching conflicts to a locally configured notes driver whose command must be trusted and available. For the science lab, add one near-miss that exposes committing a driver name and assuming every clone has a safe implementation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Predict the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A named merge driver requires configuration that defines its command, markers and recursive behaviour; the attribute only selects the name.” Apply this procedure: Document setup, fail clearly when absent and include a reproducible conflict test. The expected mechanism is: The attribute routes matching conflicts to a locally configured notes driver whose command must be trusted and available. For the documentation release, add one near-miss that exposes committing a driver name and assuming every clone has a safe implementation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: template repository. Contrast the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A named merge driver requires configuration that defines its command, markers and recursive behaviour; the attribute only selects the name.” Apply this procedure: Document setup, fail clearly when absent and include a reproducible conflict test. The expected mechanism is: The attribute routes matching conflicts to a locally configured notes driver whose command must be trusted and available. For the template repository, add one near-miss that exposes committing a driver name and assuming every clone has a safe implementation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: merge rehearsal. Stress-test the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A named merge driver requires configuration that defines its command, markers and recursive behaviour; the attribute only selects the name.” Apply this procedure: Document setup, fail clearly when absent and include a reproducible conflict test. The expected mechanism is: The attribute routes matching conflicts to a locally configured notes driver whose command must be trusted and available. For the merge rehearsal, add one near-miss that exposes committing a driver name and assuming every clone has a safe implementation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers committing a driver name and assuming every clone has a safe implementation.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Document setup, fail clearly when absent and include a reproducible conflict test.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny website project with HTML, CSS, minified assets and media files. Include one ordinary case, one boundary and one deliberate failure caused by committing a driver name and assuming every clone has a safe implementation. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A named merge driver requires configuration that defines its command, markers and recursive behaviour; the attribute only selects the name. It shows a trace, not only a final value. The ordinary case should demonstrate “The attribute routes matching conflicts to a locally configured notes driver whose command must be trusted and available.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Document setup, fail clearly when absent and include a reproducible conflict test. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
The filter attribute can run clean conversion toward repository form and smudge conversion toward working-tree form. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using filters for secrets or relying on them without a recovery plan. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Specify deterministic transformations, test round trips and keep sensitive data outside version control.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.tmpl filter=studentnameExplained result. Matching templates invoke the configured filter on check-in and checkout; the rule itself does not define the command. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: template repository. Predict the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The filter attribute can run clean conversion toward repository form and smudge conversion toward working-tree form.” Apply this procedure: Specify deterministic transformations, test round trips and keep sensitive data outside version control. The expected mechanism is: Matching templates invoke the configured filter on check-in and checkout; the rule itself does not define the command. For the template repository, add one near-miss that exposes using filters for secrets or relying on them without a recovery plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: merge rehearsal. Contrast the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The filter attribute can run clean conversion toward repository form and smudge conversion toward working-tree form.” Apply this procedure: Specify deterministic transformations, test round trips and keep sensitive data outside version control. The expected mechanism is: Matching templates invoke the configured filter on check-in and checkout; the rule itself does not define the command. For the merge rehearsal, add one near-miss that exposes using filters for secrets or relying on them without a recovery plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Stress-test the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The filter attribute can run clean conversion toward repository form and smudge conversion toward working-tree form.” Apply this procedure: Specify deterministic transformations, test round trips and keep sensitive data outside version control. The expected mechanism is: Matching templates invoke the configured filter on check-in and checkout; the rule itself does not define the command. For the coding project, add one near-miss that exposes using filters for secrets or relying on them without a recovery plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Explain the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The filter attribute can run clean conversion toward repository form and smudge conversion toward working-tree form.” Apply this procedure: Specify deterministic transformations, test round trips and keep sensitive data outside version control. The expected mechanism is: Matching templates invoke the configured filter on check-in and checkout; the rule itself does not define the command. For the group assignment, add one near-miss that exposes using filters for secrets or relying on them without a recovery plan. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using filters for secrets or relying on them without a recovery plan.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Specify deterministic transformations, test round trips and keep sensitive data outside version control.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny science lab with plain-text observations and instrument binaries. Include one ordinary case, one boundary and one deliberate failure caused by using filters for secrets or relying on them without a recovery plan. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The filter attribute can run clean conversion toward repository form and smudge conversion toward working-tree form. It shows a trace, not only a final value. The ordinary case should demonstrate “Matching templates invoke the configured filter on check-in and checkout; the rule itself does not define the command.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Specify deterministic transformations, test round trips and keep sensitive data outside version control. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
A filter driver marked required turns missing or failed filtering into an error instead of silently treating the content as usable. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is marking a fragile filter required before every collaborator and build environment can run it. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test fresh clones, CI and failure messages before enforcing the requirement.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
[filter "artifact"]
required = trueExplained result. Operations needing the artifact filter fail when its promised conversion cannot be performed. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Contrast the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A filter driver marked required turns missing or failed filtering into an error instead of silently treating the content as usable.” Apply this procedure: Test fresh clones, CI and failure messages before enforcing the requirement. The expected mechanism is: Operations needing the artifact filter fail when its promised conversion cannot be performed. For the coding project, add one near-miss that exposes marking a fragile filter required before every collaborator and build environment can run it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Stress-test the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A filter driver marked required turns missing or failed filtering into an error instead of silently treating the content as usable.” Apply this procedure: Test fresh clones, CI and failure messages before enforcing the requirement. The expected mechanism is: Operations needing the artifact filter fail when its promised conversion cannot be performed. For the group assignment, add one near-miss that exposes marking a fragile filter required before every collaborator and build environment can run it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: data folder. Explain the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A filter driver marked required turns missing or failed filtering into an error instead of silently treating the content as usable.” Apply this procedure: Test fresh clones, CI and failure messages before enforcing the requirement. The expected mechanism is: Operations needing the artifact filter fail when its promised conversion cannot be performed. For the data folder, add one near-miss that exposes marking a fragile filter required before every collaborator and build environment can run it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: website project. Transfer the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A filter driver marked required turns missing or failed filtering into an error instead of silently treating the content as usable.” Apply this procedure: Test fresh clones, CI and failure messages before enforcing the requirement. The expected mechanism is: Operations needing the artifact filter fail when its promised conversion cannot be performed. For the website project, add one near-miss that exposes marking a fragile filter required before every collaborator and build environment can run it. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers marking a fragile filter required before every collaborator and build environment can run it.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test fresh clones, CI and failure messages before enforcing the requirement.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny documentation release with Markdown sources and files excluded from archives. Include one ordinary case, one boundary and one deliberate failure caused by marking a fragile filter required before every collaborator and build environment can run it. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A filter driver marked required turns missing or failed filtering into an error instead of silently treating the content as usable. It shows a trace, not only a final value. The ordinary case should demonstrate “Operations needing the artifact filter fail when its promised conversion cannot be performed.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test fresh clones, CI and failure messages before enforcing the requirement. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
git archive can omit paths marked export-ignore and substitute selected format placeholders in files marked export-subst. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is expecting export-ignore to remove files from commits, clones or ordinary checkouts. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect the archive listing and compare it with the repository tree.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
/tests/ export-ignore
/version.txt export-substExplained result. Tests remain versioned but can be left out of archives; the version file is eligible for archive-time substitutions. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: data folder. Stress-test the rule using CSV inputs, large exports and compressed archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git archive can omit paths marked export-ignore and substitute selected format placeholders in files marked export-subst.” Apply this procedure: Inspect the archive listing and compare it with the repository tree. The expected mechanism is: Tests remain versioned but can be left out of archives; the version file is eligible for archive-time substitutions. For the data folder, add one near-miss that exposes expecting export-ignore to remove files from commits, clones or ordinary checkouts. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: website project. Explain the rule using HTML, CSS, minified assets and media files. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git archive can omit paths marked export-ignore and substitute selected format placeholders in files marked export-subst.” Apply this procedure: Inspect the archive listing and compare it with the repository tree. The expected mechanism is: Tests remain versioned but can be left out of archives; the version file is eligible for archive-time substitutions. For the website project, add one near-miss that exposes expecting export-ignore to remove files from commits, clones or ordinary checkouts. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: science lab. Transfer the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git archive can omit paths marked export-ignore and substitute selected format placeholders in files marked export-subst.” Apply this procedure: Inspect the archive listing and compare it with the repository tree. The expected mechanism is: Tests remain versioned but can be left out of archives; the version file is eligible for archive-time substitutions. For the science lab, add one near-miss that exposes expecting export-ignore to remove files from commits, clones or ordinary checkouts. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Predict the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git archive can omit paths marked export-ignore and substitute selected format placeholders in files marked export-subst.” Apply this procedure: Inspect the archive listing and compare it with the repository tree. The expected mechanism is: Tests remain versioned but can be left out of archives; the version file is eligible for archive-time substitutions. For the documentation release, add one near-miss that exposes expecting export-ignore to remove files from commits, clones or ordinary checkouts. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers expecting export-ignore to remove files from commits, clones or ordinary checkouts.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect the archive listing and compare it with the repository tree.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny template repository with placeholders transformed only by an explicit filter. Include one ordinary case, one boundary and one deliberate failure caused by expecting export-ignore to remove files from commits, clones or ordinary checkouts. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: git archive can omit paths marked export-ignore and substitute selected format placeholders in files marked export-subst. It shows a trace, not only a final value. The ordinary case should demonstrate “Tests remain versioned but can be left out of archives; the version file is eligible for archive-time substitutions.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect the archive listing and compare it with the repository tree. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
CHAPTER 19 OF 20 . Transfer with judgment
19. Conflict-marker size and specialised policies
Attributes such as conflict-marker-size can tune selected path behaviour, but repository policy should remain comprehensible and narrowly scoped. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is adding clever per-path rules without fixtures or ownership documentation. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. For every non-default attribute, keep one reason, one test path and one recovery note.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
*.json conflict-marker-size=32Explained result. Conflicts in matching JSON files use longer marker runs, which can make markers easier to distinguish from content. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: science lab. Explain the rule using plain-text observations and instrument binaries. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes such as conflict-marker-size can tune selected path behaviour, but repository policy should remain comprehensible and narrowly scoped.” Apply this procedure: For every non-default attribute, keep one reason, one test path and one recovery note. The expected mechanism is: Conflicts in matching JSON files use longer marker runs, which can make markers easier to distinguish from content. For the science lab, add one near-miss that exposes adding clever per-path rules without fixtures or ownership documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Transfer the rule using Markdown sources and files excluded from archives. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes such as conflict-marker-size can tune selected path behaviour, but repository policy should remain comprehensible and narrowly scoped.” Apply this procedure: For every non-default attribute, keep one reason, one test path and one recovery note. The expected mechanism is: Conflicts in matching JSON files use longer marker runs, which can make markers easier to distinguish from content. For the documentation release, add one near-miss that exposes adding clever per-path rules without fixtures or ownership documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: template repository. Predict the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes such as conflict-marker-size can tune selected path behaviour, but repository policy should remain comprehensible and narrowly scoped.” Apply this procedure: For every non-default attribute, keep one reason, one test path and one recovery note. The expected mechanism is: Conflicts in matching JSON files use longer marker runs, which can make markers easier to distinguish from content. For the template repository, add one near-miss that exposes adding clever per-path rules without fixtures or ownership documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: merge rehearsal. Contrast the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Attributes such as conflict-marker-size can tune selected path behaviour, but repository policy should remain comprehensible and narrowly scoped.” Apply this procedure: For every non-default attribute, keep one reason, one test path and one recovery note. The expected mechanism is: Conflicts in matching JSON files use longer marker runs, which can make markers easier to distinguish from content. For the merge rehearsal, add one near-miss that exposes adding clever per-path rules without fixtures or ownership documentation. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers adding clever per-path rules without fixtures or ownership documentation.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “For every non-default attribute, keep one reason, one test path and one recovery note.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny merge rehearsal with structured files needing a documented merge policy. Include one ordinary case, one boundary and one deliberate failure caused by adding clever per-path rules without fixtures or ownership documentation. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Attributes such as conflict-marker-size can tune selected path behaviour, but repository policy should remain comprehensible and narrowly scoped. It shows a trace, not only a final value. The ordinary case should demonstrate “Conflicts in matching JSON files use longer marker runs, which can make markers easier to distinguish from content.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: For every non-default attribute, keep one reason, one test path and one recovery note. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Reliable attribute work uses check-attr, ls-files or hash inspection, disposable clones, byte-level tests and small commits that separate policy from feature changes. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is judging success only because git status looks clean on one machine. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Create LF and CRLF fixtures, inspect index blobs, checkout twice, archive once and rehearse a conflict.
Use a two-column trace during a short Punggol home session. On the left, write the predicted state before the interpreter, browser, database or Git command runs. On the right, record the exact observation. Underneath, explain the earliest difference with one causal sentence. That small routine is more diagnostic than copying a finished answer.
Core worked example
git check-attr text eol diff merge -- sample.txt
git show :sample.txt | od -An -t x1Explained result. The first command proves effective policy; the second inspects normalized index bytes so repository state is not confused with editor presentation. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: template repository. Transfer the rule using placeholders transformed only by an explicit filter. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable attribute work uses check-attr, ls-files or hash inspection, disposable clones, byte-level tests and small commits that separate policy from feature changes.” Apply this procedure: Create LF and CRLF fixtures, inspect index blobs, checkout twice, archive once and rehearse a conflict. The expected mechanism is: The first command proves effective policy; the second inspects normalized index bytes so repository state is not confused with editor presentation. For the template repository, add one near-miss that exposes judging success only because git status looks clean on one machine. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: merge rehearsal. Predict the rule using structured files needing a documented merge policy. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable attribute work uses check-attr, ls-files or hash inspection, disposable clones, byte-level tests and small commits that separate policy from feature changes.” Apply this procedure: Create LF and CRLF fixtures, inspect index blobs, checkout twice, archive once and rehearse a conflict. The expected mechanism is: The first command proves effective policy; the second inspects normalized index bytes so repository state is not confused with editor presentation. For the merge rehearsal, add one near-miss that exposes judging success only because git status looks clean on one machine. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Contrast the rule using source files, generated reports and binary screenshots. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable attribute work uses check-attr, ls-files or hash inspection, disposable clones, byte-level tests and small commits that separate policy from feature changes.” Apply this procedure: Create LF and CRLF fixtures, inspect index blobs, checkout twice, archive once and rehearse a conflict. The expected mechanism is: The first command proves effective policy; the second inspects normalized index bytes so repository state is not confused with editor presentation. For the coding project, add one near-miss that exposes judging success only because git status looks clean on one machine. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Stress-test the rule using notes edited on Windows, macOS and Linux. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable attribute work uses check-attr, ls-files or hash inspection, disposable clones, byte-level tests and small commits that separate policy from feature changes.” Apply this procedure: Create LF and CRLF fixtures, inspect index blobs, checkout twice, archive once and rehearse a conflict. The expected mechanism is: The first command proves effective policy; the second inspects normalized index bytes so repository state is not confused with editor presentation. For the group assignment, add one near-miss that exposes judging success only because git status looks clean on one machine. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers judging success only because git status looks clean on one machine.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Create LF and CRLF fixtures, inspect index blobs, checkout twice, archive once and rehearse a conflict.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final syntax. Useful prompts are: “What did you expect?”, “Which state changed first?”, “What evidence would change your mind?”, and “Can you make the example smaller?” These questions return responsibility to the learner while keeping the session calm and concrete.
Practice with an explained answer
Question. Build a tiny coding project with source files, generated reports and binary screenshots. Include one ordinary case, one boundary and one deliberate failure caused by judging success only because git status looks clean on one machine. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Reliable attribute work uses check-attr, ls-files or hash inspection, disposable clones, byte-level tests and small commits that separate policy from feature changes. It shows a trace, not only a final value. The ordinary case should demonstrate “The first command proves effective policy; the second inspects normalized index bytes so repository state is not confused with editor presentation.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Create LF and CRLF fixtures, inspect index blobs, checkout twice, archive once and rehearse a conflict. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
Separate mechanism from project policy. The mechanism is the behaviour guaranteed by the current official documentation. The policy is the choice this project makes about validation, ordering, ownership, performance or recovery. Write both statements before generalising. Keep important work backed up and use disposable examples for destructive or stateful experiments.
Previous chapter . Contents . Next chapter
Parent guide: choose the next useful step
Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.
Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.
Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.
Capstone practice with explained routes
1. coding project: model, boundary and recovery
Create a small coding project using source files, generated reports and binary screenshots. Combine “Attributes as path metadata” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Attributes are selected by pathname patterns and consumed by particular Git features; they are not general shell flags or file permissions. Apply: Name the path, resolved attribute and consuming Git operation separately. Verify: Text files are marked for text handling and PNG files receive the binary macro when relevant operations inspect them. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
2. group assignment: model, boundary and recovery
Create a small group assignment using notes edited on Windows, macOS and Linux. Combine “Set, unset, value and unspecified states” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: An attribute can be Set, Unset, assigned a string value or left Unspecified, and consumers interpret those states according to their own contracts. Apply: Ask git check-attr for the exact attribute and record the four possible states. Verify: dat files have text Unset; Markdown files assign the value markdown to diff. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
3. data folder: model, boundary and recovery
Create a small data folder using CSV inputs, large exports and compressed archives. Combine “Automatic text detection” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: text=auto lets Git decide whether content appears text-like for normalization, while explicit text or -text states override that automatic judgment. Apply: Test representative fixtures and explicitly mark formats whose treatment must not depend on heuristics. Verify: Git automatically decides text normalization for paths not governed by a more specific rule. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
4. website project: model, boundary and recovery
Create a small website project using HTML, CSS, minified assets and media files. Combine “Safe migration in a mixed-platform team” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: An EOL migration should freeze unrelated edits, establish one policy, renormalize once and let each collaborator refresh clean worktrees. Apply: Create a clean migration branch, communicate timing and verify clones on two platforms. Verify: A clean starting state makes changed lines attributable to policy rather than hidden personal edits. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
5. science lab: model, boundary and recovery
Create a small science lab using plain-text observations and instrument binaries. Combine “Word diff and hunk headers” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Diff drivers can define word regexes and function-name patterns that improve human review without changing file content. Apply: Use fixtures containing punctuation and headings, then compare ordinary and word diff output. Verify: Markdown diff hunks can show nearby heading lines as context when the driver is selected. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
6. documentation release: model, boundary and recovery
Create a small documentation release using Markdown sources and files excluded from archives. Combine “Filter drivers and clean/smudge” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: The filter attribute can run clean conversion toward repository form and smudge conversion toward working-tree form. Apply: Specify deterministic transformations, test round trips and keep sensitive data outside version control. Verify: Matching templates invoke the configured filter on check-in and checkout; the rule itself does not define the command. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
7. template repository: model, boundary and recovery
Create a small template repository using placeholders transformed only by an explicit filter. Combine “Conflict-marker size and specialised policies” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Attributes such as conflict-marker-size can tune selected path behaviour, but repository policy should remain comprehensible and narrowly scoped. Apply: For every non-default attribute, keep one reason, one test path and one recovery note. Verify: Conflicts in matching JSON files use longer marker runs, which can make markers easier to distinguish from content. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
8. merge rehearsal: model, boundary and recovery
Create a small merge rehearsal using structured files needing a documented merge policy. Combine “Where attribute rules come from” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Git can read attributes from repository .gitattributes files, .git/info/attributes and configured system or global locations, with precedence depending on source and directory depth. Apply: Use git check-attr with –source where supported and inspect rules from closest to broadest scope. Verify: The output reveals the effective attributes for that path instead of relying on memory. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
Frequently asked questions
How long should a practice session be?
Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.
Should every option or function be memorised?
No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.
What if the result is correct but the explanation is weak?
Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.
Is the shortest solution the best?
Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.
When should official documentation be used?
Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.
How can a parent help without technical expertise?
Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.
How do we test transfer?
Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.
What should be saved after practice?
Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.
Can these exercises replace backups?
No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.
What counts as mastery?
The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.
