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 sparse-checkout reduces which tracked paths appear in a working tree while the repository still knows about the full commit. It is not a partial-history tool and not an ignore rule; the learner must separate repository objects, the index’s sparse state and the files currently materialised on disk. 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
Sparse checkout changes which tracked paths are present in one working tree while commits and repository history still describe the complete tree. 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 calling the result a partial clone and assuming absent files are not in repository data. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Draw history, index and working tree as separate layers before running a command.
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 sparse-checkout listExplained result. The command reports sparse path rules, not a list of objects downloaded from history. 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: school monorepo. Predict the rule using one subject app, shared libraries and documentation. 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 “Sparse checkout changes which tracked paths are present in one working tree while commits and repository history still describe the complete tree.” Apply this procedure: Draw history, index and working tree as separate layers before running a command. The expected mechanism is: The command reports sparse path rules, not a list of objects downloaded from history. For the school monorepo, add one near-miss that exposes calling the result a partial clone and assuming absent files are not in repository data. 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 repository. Contrast the rule using content, theme, media tooling and deployment scripts. 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 “Sparse checkout changes which tracked paths are present in one working tree while commits and repository history still describe the complete tree.” Apply this procedure: Draw history, index and working tree as separate layers before running a command. The expected mechanism is: The command reports sparse path rules, not a list of objects downloaded from history. For the website repository, add one near-miss that exposes calling the result a partial clone and assuming absent files are not in repository data. 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 project. Stress-test the rule using notebooks, source tables, generated output and tests. 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 “Sparse checkout changes which tracked paths are present in one working tree while commits and repository history still describe the complete tree.” Apply this procedure: Draw history, index and working tree as separate layers before running a command. The expected mechanism is: The command reports sparse path rules, not a list of objects downloaded from history. For the data project, add one near-miss that exposes calling the result a partial clone and assuming absent files are not in repository data. 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: coding CCA repo. Explain the rule using team folders, shared utilities and challenge 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 “Sparse checkout changes which tracked paths are present in one working tree while commits and repository history still describe the complete tree.” Apply this procedure: Draw history, index and working tree as separate layers before running a command. The expected mechanism is: The command reports sparse path rules, not a list of objects downloaded from history. For the coding CCA repo, add one near-miss that exposes calling the result a partial clone and assuming absent files are not in repository data. 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 calling the result a partial clone and assuming absent files are not in repository data.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Draw history, index and working tree as separate layers before running a command.” 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 mobile project with application, backend, packages and design assets. Include one ordinary case, one boundary and one deliberate failure caused by calling the result a partial clone and assuming absent files are not in repository data. 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: Sparse checkout changes which tracked paths are present in one working tree while commits and repository history still describe the complete tree. It shows a trace, not only a final value. The ordinary case should demonstrate “The command reports sparse path rules, not a list of objects downloaded from history.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Draw history, index and working tree as separate layers before running a command. 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
Cone mode uses directory-oriented patterns and is the recommended efficient model for common monorepo workflows. 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 feeding arbitrary gitignore-style patterns into cone mode. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Choose directories as ownership units or explicitly justify non-cone mode.
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 sparse-checkout set app shared/libExplained result. The working tree focuses on the selected directories plus required parent files. 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 project. Contrast the rule using notebooks, source tables, generated output and tests. 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 “Cone mode uses directory-oriented patterns and is the recommended efficient model for common monorepo workflows.” Apply this procedure: Choose directories as ownership units or explicitly justify non-cone mode. The expected mechanism is: The working tree focuses on the selected directories plus required parent files. For the data project, add one near-miss that exposes feeding arbitrary gitignore-style patterns into cone mode. 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: coding CCA repo. Stress-test the rule using team folders, shared utilities and challenge 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 “Cone mode uses directory-oriented patterns and is the recommended efficient model for common monorepo workflows.” Apply this procedure: Choose directories as ownership units or explicitly justify non-cone mode. The expected mechanism is: The working tree focuses on the selected directories plus required parent files. For the coding CCA repo, add one near-miss that exposes feeding arbitrary gitignore-style patterns into cone mode. 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: revision archive. Explain the rule using year folders, subject notes and common templates. 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 “Cone mode uses directory-oriented patterns and is the recommended efficient model for common monorepo workflows.” Apply this procedure: Choose directories as ownership units or explicitly justify non-cone mode. The expected mechanism is: The working tree focuses on the selected directories plus required parent files. For the revision archive, add one near-miss that exposes feeding arbitrary gitignore-style patterns into cone mode. 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: mobile project. Transfer the rule using application, backend, packages and design assets. 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 “Cone mode uses directory-oriented patterns and is the recommended efficient model for common monorepo workflows.” Apply this procedure: Choose directories as ownership units or explicitly justify non-cone mode. The expected mechanism is: The working tree focuses on the selected directories plus required parent files. For the mobile project, add one near-miss that exposes feeding arbitrary gitignore-style patterns into cone mode. 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 feeding arbitrary gitignore-style patterns into cone mode.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Choose directories as ownership units or explicitly justify non-cone mode.” 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 repo with guides, examples, localisation and build tools. Include one ordinary case, one boundary and one deliberate failure caused by feeding arbitrary gitignore-style patterns into cone mode. 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: Cone mode uses directory-oriented patterns and is the recommended efficient model for common monorepo workflows. It shows a trace, not only a final value. The ordinary case should demonstrate “The working tree focuses on the selected directories plus required parent files.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Choose directories as ownership units or explicitly justify non-cone mode. 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
Non-cone mode accepts more general patterns but has warnings, complexity and weaker scaling characteristics. 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 choosing it merely to save one extra file without understanding pattern semantics. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Start with cone mode and use non-cone only for a documented, tested need.
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 sparse-checkout set --no-cone '/app/*' '!/app/tmp/'Explained result. The rule set behaves like sparse patterns and must be reviewed as such. 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: revision archive. Stress-test the rule using year folders, subject notes and common templates. 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 “Non-cone mode accepts more general patterns but has warnings, complexity and weaker scaling characteristics.” Apply this procedure: Start with cone mode and use non-cone only for a documented, tested need. The expected mechanism is: The rule set behaves like sparse patterns and must be reviewed as such. For the revision archive, add one near-miss that exposes choosing it merely to save one extra file without understanding pattern semantics. 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: mobile project. Explain the rule using application, backend, packages and design assets. 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 “Non-cone mode accepts more general patterns but has warnings, complexity and weaker scaling characteristics.” Apply this procedure: Start with cone mode and use non-cone only for a documented, tested need. The expected mechanism is: The rule set behaves like sparse patterns and must be reviewed as such. For the mobile project, add one near-miss that exposes choosing it merely to save one extra file without understanding pattern semantics. 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: documentation repo. Transfer the rule using guides, examples, localisation and build tools. 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 “Non-cone mode accepts more general patterns but has warnings, complexity and weaker scaling characteristics.” Apply this procedure: Start with cone mode and use non-cone only for a documented, tested need. The expected mechanism is: The rule set behaves like sparse patterns and must be reviewed as such. For the documentation repo, add one near-miss that exposes choosing it merely to save one extra file without understanding pattern semantics. 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: recovery lab. Predict the rule using disposable branches, untracked files and sparse patterns. 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 “Non-cone mode accepts more general patterns but has warnings, complexity and weaker scaling characteristics.” Apply this procedure: Start with cone mode and use non-cone only for a documented, tested need. The expected mechanism is: The rule set behaves like sparse patterns and must be reviewed as such. For the recovery lab, add one near-miss that exposes choosing it merely to save one extra file without understanding pattern semantics. 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 choosing it merely to save one extra file without understanding pattern semantics.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Start with cone mode and use non-cone only for a documented, tested need.” 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 recovery lab with disposable branches, untracked files and sparse patterns. Include one ordinary case, one boundary and one deliberate failure caused by choosing it merely to save one extra file without understanding pattern semantics. 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: Non-cone mode accepts more general patterns but has warnings, complexity and weaker scaling characteristics. It shows a trace, not only a final value. The ordinary case should demonstrate “The rule set behaves like sparse patterns and must be reviewed as such.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Start with cone mode and use non-cone only for a documented, tested need. 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
init enables sparse-checkout configuration for the current worktree and establishes an initial mode, though set can perform necessary setup in modern workflows. 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 commands from the wrong worktree and changing an unintended checkout. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Record pwd, branch and git worktree list before enabling sparsity.
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 sparse-checkout init --coneExplained result. The current worktree enters cone-mode sparse operation. 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: documentation repo. Explain the rule using guides, examples, localisation and build tools. 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 “init enables sparse-checkout configuration for the current worktree and establishes an initial mode, though set can perform necessary setup in modern workflows.” Apply this procedure: Record pwd, branch and git worktree list before enabling sparsity. The expected mechanism is: The current worktree enters cone-mode sparse operation. For the documentation repo, add one near-miss that exposes running commands from the wrong worktree and changing an unintended checkout. 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: recovery lab. Transfer the rule using disposable branches, untracked files and sparse patterns. 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 “init enables sparse-checkout configuration for the current worktree and establishes an initial mode, though set can perform necessary setup in modern workflows.” Apply this procedure: Record pwd, branch and git worktree list before enabling sparsity. The expected mechanism is: The current worktree enters cone-mode sparse operation. For the recovery lab, add one near-miss that exposes running commands from the wrong worktree and changing an unintended checkout. 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: school monorepo. Predict the rule using one subject app, shared libraries and documentation. 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 “init enables sparse-checkout configuration for the current worktree and establishes an initial mode, though set can perform necessary setup in modern workflows.” Apply this procedure: Record pwd, branch and git worktree list before enabling sparsity. The expected mechanism is: The current worktree enters cone-mode sparse operation. For the school monorepo, add one near-miss that exposes running commands from the wrong worktree and changing an unintended checkout. 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 repository. Contrast the rule using content, theme, media tooling and deployment scripts. 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 “init enables sparse-checkout configuration for the current worktree and establishes an initial mode, though set can perform necessary setup in modern workflows.” Apply this procedure: Record pwd, branch and git worktree list before enabling sparsity. The expected mechanism is: The current worktree enters cone-mode sparse operation. For the website repository, add one near-miss that exposes running commands from the wrong worktree and changing an unintended checkout. 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 commands from the wrong worktree and changing an unintended checkout.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Record pwd, branch and git worktree list before enabling sparsity.” 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 school monorepo with one subject app, shared libraries and documentation. Include one ordinary case, one boundary and one deliberate failure caused by running commands from the wrong worktree and changing an unintended checkout. 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: init enables sparse-checkout configuration for the current worktree and establishes an initial mode, though set can perform necessary setup in modern workflows. It shows a trace, not only a final value. The ordinary case should demonstrate “The current worktree enters cone-mode sparse operation.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Record pwd, branch and git worktree list before enabling sparsity. 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
set updates the desired sparse paths and makes the working tree match the new specification. 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 set as additive and accidentally dropping a previously selected directory. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Read list first or use add when accumulation is intended.
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 sparse-checkout set frontend packages/uiExplained result. Only the new selected directory set remains in the specification. 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: school monorepo. Transfer the rule using one subject app, shared libraries and documentation. 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 “set updates the desired sparse paths and makes the working tree match the new specification.” Apply this procedure: Read list first or use add when accumulation is intended. The expected mechanism is: Only the new selected directory set remains in the specification. For the school monorepo, add one near-miss that exposes treating set as additive and accidentally dropping a previously selected directory. 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 repository. Predict the rule using content, theme, media tooling and deployment scripts. 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 “set updates the desired sparse paths and makes the working tree match the new specification.” Apply this procedure: Read list first or use add when accumulation is intended. The expected mechanism is: Only the new selected directory set remains in the specification. For the website repository, add one near-miss that exposes treating set as additive and accidentally dropping a previously selected directory. 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 project. Contrast the rule using notebooks, source tables, generated output and tests. 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 “set updates the desired sparse paths and makes the working tree match the new specification.” Apply this procedure: Read list first or use add when accumulation is intended. The expected mechanism is: Only the new selected directory set remains in the specification. For the data project, add one near-miss that exposes treating set as additive and accidentally dropping a previously selected directory. 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: coding CCA repo. Stress-test the rule using team folders, shared utilities and challenge 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 “set updates the desired sparse paths and makes the working tree match the new specification.” Apply this procedure: Read list first or use add when accumulation is intended. The expected mechanism is: Only the new selected directory set remains in the specification. For the coding CCA repo, add one near-miss that exposes treating set as additive and accidentally dropping a previously selected directory. 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 set as additive and accidentally dropping a previously selected directory.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Read list first or use add when accumulation is intended.” 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 repository with content, theme, media tooling and deployment scripts. Include one ordinary case, one boundary and one deliberate failure caused by treating set as additive and accidentally dropping a previously selected directory. 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: set updates the desired sparse paths and makes the working tree match the new specification. It shows a trace, not only a final value. The ordinary case should demonstrate “Only the new selected directory set remains in the specification.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Read list first or use add when accumulation is intended. 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
add adds paths to the current sparse specification without replacing existing selections. 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 add repeatedly without documenting the final ownership boundary. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Review list after the change and keep the set intentionally small.
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 sparse-checkout add docsExplained result. docs joins the directories already materialised by the sparse specification. 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 project. Predict the rule using notebooks, source tables, generated output and tests. 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 “add adds paths to the current sparse specification without replacing existing selections.” Apply this procedure: Review list after the change and keep the set intentionally small. The expected mechanism is: docs joins the directories already materialised by the sparse specification. For the data project, add one near-miss that exposes using add repeatedly without documenting the final ownership boundary. 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: coding CCA repo. Contrast the rule using team folders, shared utilities and challenge 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 “add adds paths to the current sparse specification without replacing existing selections.” Apply this procedure: Review list after the change and keep the set intentionally small. The expected mechanism is: docs joins the directories already materialised by the sparse specification. For the coding CCA repo, add one near-miss that exposes using add repeatedly without documenting the final ownership boundary. 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: revision archive. Stress-test the rule using year folders, subject notes and common templates. 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 “add adds paths to the current sparse specification without replacing existing selections.” Apply this procedure: Review list after the change and keep the set intentionally small. The expected mechanism is: docs joins the directories already materialised by the sparse specification. For the revision archive, add one near-miss that exposes using add repeatedly without documenting the final ownership boundary. 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: mobile project. Explain the rule using application, backend, packages and design assets. 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 “add adds paths to the current sparse specification without replacing existing selections.” Apply this procedure: Review list after the change and keep the set intentionally small. The expected mechanism is: docs joins the directories already materialised by the sparse specification. For the mobile project, add one near-miss that exposes using add repeatedly without documenting the final ownership boundary. 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 add repeatedly without documenting the final ownership boundary.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Review list after the change and keep the set intentionally small.” 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 project with notebooks, source tables, generated output and tests. Include one ordinary case, one boundary and one deliberate failure caused by using add repeatedly without documenting the final ownership boundary. 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: add adds paths to the current sparse specification without replacing existing selections. It shows a trace, not only a final value. The ordinary case should demonstrate “docs joins the directories already materialised by the sparse specification.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Review list after the change and keep the set intentionally small. 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
list provides the selected sparse paths in the user-facing specification. 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 a filesystem listing as proof of the rules when ignored or untracked files remain. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare sparse rules with git status and tracked files.
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 sparse-checkout listExplained result. The output states the current sparse selection independently of incidental files on disk. 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: revision archive. Contrast the rule using year folders, subject notes and common templates. 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 “list provides the selected sparse paths in the user-facing specification.” Apply this procedure: Compare sparse rules with git status and tracked files. The expected mechanism is: The output states the current sparse selection independently of incidental files on disk. For the revision archive, add one near-miss that exposes using a filesystem listing as proof of the rules when ignored or untracked files remain. 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: mobile project. Stress-test the rule using application, backend, packages and design assets. 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 “list provides the selected sparse paths in the user-facing specification.” Apply this procedure: Compare sparse rules with git status and tracked files. The expected mechanism is: The output states the current sparse selection independently of incidental files on disk. For the mobile project, add one near-miss that exposes using a filesystem listing as proof of the rules when ignored or untracked files remain. 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: documentation repo. Explain the rule using guides, examples, localisation and build tools. 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 “list provides the selected sparse paths in the user-facing specification.” Apply this procedure: Compare sparse rules with git status and tracked files. The expected mechanism is: The output states the current sparse selection independently of incidental files on disk. For the documentation repo, add one near-miss that exposes using a filesystem listing as proof of the rules when ignored or untracked files remain. 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: recovery lab. Transfer the rule using disposable branches, untracked files and sparse patterns. 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 “list provides the selected sparse paths in the user-facing specification.” Apply this procedure: Compare sparse rules with git status and tracked files. The expected mechanism is: The output states the current sparse selection independently of incidental files on disk. For the recovery lab, add one near-miss that exposes using a filesystem listing as proof of the rules when ignored or untracked files remain. 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 a filesystem listing as proof of the rules when ignored or untracked files remain.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Compare sparse rules with git status and tracked files.” 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 CCA repo with team folders, shared utilities and challenge archives. Include one ordinary case, one boundary and one deliberate failure caused by using a filesystem listing as proof of the rules when ignored or untracked files remain. 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: list provides the selected sparse paths in the user-facing specification. It shows a trace, not only a final value. The ordinary case should demonstrate “The output states the current sparse selection independently of incidental files on disk.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Compare sparse rules with git status and tracked files. 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
reapply makes the working tree conform again after operations or conflicts leave paths expanded or skip-worktree states disturbed. 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 deleting unexpected files manually before understanding why they appeared. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Check status, preserve work and then reapply the known specification.
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 sparse-checkout reapplyExplained result. Tracked paths outside the desired sparse set are reconsidered according to current rules. 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: documentation repo. Stress-test the rule using guides, examples, localisation and build tools. 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 “reapply makes the working tree conform again after operations or conflicts leave paths expanded or skip-worktree states disturbed.” Apply this procedure: Check status, preserve work and then reapply the known specification. The expected mechanism is: Tracked paths outside the desired sparse set are reconsidered according to current rules. For the documentation repo, add one near-miss that exposes deleting unexpected files manually before understanding why they appeared. 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: recovery lab. Explain the rule using disposable branches, untracked files and sparse patterns. 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 “reapply makes the working tree conform again after operations or conflicts leave paths expanded or skip-worktree states disturbed.” Apply this procedure: Check status, preserve work and then reapply the known specification. The expected mechanism is: Tracked paths outside the desired sparse set are reconsidered according to current rules. For the recovery lab, add one near-miss that exposes deleting unexpected files manually before understanding why they appeared. 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: school monorepo. Transfer the rule using one subject app, shared libraries and documentation. 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 “reapply makes the working tree conform again after operations or conflicts leave paths expanded or skip-worktree states disturbed.” Apply this procedure: Check status, preserve work and then reapply the known specification. The expected mechanism is: Tracked paths outside the desired sparse set are reconsidered according to current rules. For the school monorepo, add one near-miss that exposes deleting unexpected files manually before understanding why they appeared. 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 repository. Predict the rule using content, theme, media tooling and deployment scripts. 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 “reapply makes the working tree conform again after operations or conflicts leave paths expanded or skip-worktree states disturbed.” Apply this procedure: Check status, preserve work and then reapply the known specification. The expected mechanism is: Tracked paths outside the desired sparse set are reconsidered according to current rules. For the website repository, add one near-miss that exposes deleting unexpected files manually before understanding why they appeared. 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 deleting unexpected files manually before understanding why they appeared.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Check status, preserve work and then reapply the known specification.” 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 revision archive with year folders, subject notes and common templates. Include one ordinary case, one boundary and one deliberate failure caused by deleting unexpected files manually before understanding why they appeared. 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: reapply makes the working tree conform again after operations or conflicts leave paths expanded or skip-worktree states disturbed. It shows a trace, not only a final value. The ordinary case should demonstrate “Tracked paths outside the desired sparse set are reconsidered according to current rules.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Check status, preserve work and then reapply the known specification. 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
disable turns off sparse checkout for the current worktree and restores tracked files for the full tree. 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 deleting sparse configuration by hand and leaving inconsistent index state. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use the porcelain command and verify status before and after.
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 sparse-checkout disableExplained result. The worktree returns to ordinary full-tree materialisation. 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: school monorepo. Explain the rule using one subject app, shared libraries and documentation. 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 “disable turns off sparse checkout for the current worktree and restores tracked files for the full tree.” Apply this procedure: Use the porcelain command and verify status before and after. The expected mechanism is: The worktree returns to ordinary full-tree materialisation. For the school monorepo, add one near-miss that exposes deleting sparse configuration by hand and leaving inconsistent index state. 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 repository. Transfer the rule using content, theme, media tooling and deployment scripts. 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 “disable turns off sparse checkout for the current worktree and restores tracked files for the full tree.” Apply this procedure: Use the porcelain command and verify status before and after. The expected mechanism is: The worktree returns to ordinary full-tree materialisation. For the website repository, add one near-miss that exposes deleting sparse configuration by hand and leaving inconsistent index state. 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 project. Predict the rule using notebooks, source tables, generated output and tests. 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 “disable turns off sparse checkout for the current worktree and restores tracked files for the full tree.” Apply this procedure: Use the porcelain command and verify status before and after. The expected mechanism is: The worktree returns to ordinary full-tree materialisation. For the data project, add one near-miss that exposes deleting sparse configuration by hand and leaving inconsistent index state. 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: coding CCA repo. Contrast the rule using team folders, shared utilities and challenge 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 “disable turns off sparse checkout for the current worktree and restores tracked files for the full tree.” Apply this procedure: Use the porcelain command and verify status before and after. The expected mechanism is: The worktree returns to ordinary full-tree materialisation. For the coding CCA repo, add one near-miss that exposes deleting sparse configuration by hand and leaving inconsistent index state. 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 deleting sparse configuration by hand and leaving inconsistent index state.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use the porcelain command and verify status before and after.” 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 mobile project with application, backend, packages and design assets. Include one ordinary case, one boundary and one deliberate failure caused by deleting sparse configuration by hand and leaving inconsistent index state. 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: disable turns off sparse checkout for the current worktree and restores tracked files for the full tree. It shows a trace, not only a final value. The ordinary case should demonstrate “The worktree returns to ordinary full-tree materialisation.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use the porcelain command and verify status before and after. 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
Sparse checkout uses skip-worktree index bits, but users should manage the feature with sparse-checkout commands rather than toggling bits casually. 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 skip-worktree as a promise Git will never touch a path. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use plumbing observations only for diagnosis and keep the porcelain specification authoritative.
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 ls-files -tExplained result. The diagnostic output can reveal index flags but is not the workflow interface. 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 project. Transfer the rule using notebooks, source tables, generated output and tests. 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 “Sparse checkout uses skip-worktree index bits, but users should manage the feature with sparse-checkout commands rather than toggling bits casually.” Apply this procedure: Use plumbing observations only for diagnosis and keep the porcelain specification authoritative. The expected mechanism is: The diagnostic output can reveal index flags but is not the workflow interface. For the data project, add one near-miss that exposes treating skip-worktree as a promise Git will never touch a path. 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: coding CCA repo. Predict the rule using team folders, shared utilities and challenge 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 “Sparse checkout uses skip-worktree index bits, but users should manage the feature with sparse-checkout commands rather than toggling bits casually.” Apply this procedure: Use plumbing observations only for diagnosis and keep the porcelain specification authoritative. The expected mechanism is: The diagnostic output can reveal index flags but is not the workflow interface. For the coding CCA repo, add one near-miss that exposes treating skip-worktree as a promise Git will never touch a path. 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: revision archive. Contrast the rule using year folders, subject notes and common templates. 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 “Sparse checkout uses skip-worktree index bits, but users should manage the feature with sparse-checkout commands rather than toggling bits casually.” Apply this procedure: Use plumbing observations only for diagnosis and keep the porcelain specification authoritative. The expected mechanism is: The diagnostic output can reveal index flags but is not the workflow interface. For the revision archive, add one near-miss that exposes treating skip-worktree as a promise Git will never touch a path. 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: mobile project. Stress-test the rule using application, backend, packages and design assets. 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 “Sparse checkout uses skip-worktree index bits, but users should manage the feature with sparse-checkout commands rather than toggling bits casually.” Apply this procedure: Use plumbing observations only for diagnosis and keep the porcelain specification authoritative. The expected mechanism is: The diagnostic output can reveal index flags but is not the workflow interface. For the mobile project, add one near-miss that exposes treating skip-worktree as a promise Git will never touch a path. 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 skip-worktree as a promise Git will never touch a path.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use plumbing observations only for diagnosis and keep the porcelain specification authoritative.” 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 repo with guides, examples, localisation and build tools. Include one ordinary case, one boundary and one deliberate failure caused by treating skip-worktree as a promise Git will never touch a path. 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: Sparse checkout uses skip-worktree index bits, but users should manage the feature with sparse-checkout commands rather than toggling bits casually. It shows a trace, not only a final value. The ordinary case should demonstrate “The diagnostic output can reveal index flags but is not the workflow interface.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use plumbing observations only for diagnosis and keep the porcelain specification authoritative. 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
gitignore controls untracked-file visibility and add behaviour; sparse checkout controls materialisation of tracked paths. 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 a tracked directory to .gitignore and expecting it to disappear. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Classify the path as tracked or untracked before choosing the mechanism.
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-ignore -v pathExplained result. An ignore rule does not remove a tracked path from repository history or replace sparse rules. 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: revision archive. Predict the rule using year folders, subject notes and common templates. 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 “gitignore controls untracked-file visibility and add behaviour; sparse checkout controls materialisation of tracked paths.” Apply this procedure: Classify the path as tracked or untracked before choosing the mechanism. The expected mechanism is: An ignore rule does not remove a tracked path from repository history or replace sparse rules. For the revision archive, add one near-miss that exposes adding a tracked directory to .gitignore and expecting it to disappear. 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: mobile project. Contrast the rule using application, backend, packages and design assets. 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 “gitignore controls untracked-file visibility and add behaviour; sparse checkout controls materialisation of tracked paths.” Apply this procedure: Classify the path as tracked or untracked before choosing the mechanism. The expected mechanism is: An ignore rule does not remove a tracked path from repository history or replace sparse rules. For the mobile project, add one near-miss that exposes adding a tracked directory to .gitignore and expecting it to disappear. 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: documentation repo. Stress-test the rule using guides, examples, localisation and build tools. 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 “gitignore controls untracked-file visibility and add behaviour; sparse checkout controls materialisation of tracked paths.” Apply this procedure: Classify the path as tracked or untracked before choosing the mechanism. The expected mechanism is: An ignore rule does not remove a tracked path from repository history or replace sparse rules. For the documentation repo, add one near-miss that exposes adding a tracked directory to .gitignore and expecting it to disappear. 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: recovery lab. Explain the rule using disposable branches, untracked files and sparse patterns. 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 “gitignore controls untracked-file visibility and add behaviour; sparse checkout controls materialisation of tracked paths.” Apply this procedure: Classify the path as tracked or untracked before choosing the mechanism. The expected mechanism is: An ignore rule does not remove a tracked path from repository history or replace sparse rules. For the recovery lab, add one near-miss that exposes adding a tracked directory to .gitignore and expecting it to disappear. 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 a tracked directory to .gitignore and expecting it to disappear.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Classify the path as tracked or untracked before choosing the mechanism.” 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 recovery lab with disposable branches, untracked files and sparse patterns. Include one ordinary case, one boundary and one deliberate failure caused by adding a tracked directory to .gitignore and expecting it to disappear. 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: gitignore controls untracked-file visibility and add behaviour; sparse checkout controls materialisation of tracked paths. It shows a trace, not only a final value. The ordinary case should demonstrate “An ignore rule does not remove a tracked path from repository history or replace sparse rules.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Classify the path as tracked or untracked before choosing the mechanism. 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
Sparse checkout limits the working tree, while partial clone filters object transfer and may fetch missing objects later. 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 promising disk or network savings from sparsity alone without measuring repository objects. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Measure working-tree files and object database separately; combine features only deliberately.
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 count-objects -vHExplained result. Repository-object size is evidence distinct from the sparse working-tree footprint. 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: documentation repo. Contrast the rule using guides, examples, localisation and build tools. 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 “Sparse checkout limits the working tree, while partial clone filters object transfer and may fetch missing objects later.” Apply this procedure: Measure working-tree files and object database separately; combine features only deliberately. The expected mechanism is: Repository-object size is evidence distinct from the sparse working-tree footprint. For the documentation repo, add one near-miss that exposes promising disk or network savings from sparsity alone without measuring repository objects. 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: recovery lab. Stress-test the rule using disposable branches, untracked files and sparse patterns. 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 “Sparse checkout limits the working tree, while partial clone filters object transfer and may fetch missing objects later.” Apply this procedure: Measure working-tree files and object database separately; combine features only deliberately. The expected mechanism is: Repository-object size is evidence distinct from the sparse working-tree footprint. For the recovery lab, add one near-miss that exposes promising disk or network savings from sparsity alone without measuring repository objects. 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: school monorepo. Explain the rule using one subject app, shared libraries and documentation. 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 “Sparse checkout limits the working tree, while partial clone filters object transfer and may fetch missing objects later.” Apply this procedure: Measure working-tree files and object database separately; combine features only deliberately. The expected mechanism is: Repository-object size is evidence distinct from the sparse working-tree footprint. For the school monorepo, add one near-miss that exposes promising disk or network savings from sparsity alone without measuring repository objects. 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 repository. Transfer the rule using content, theme, media tooling and deployment scripts. 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 “Sparse checkout limits the working tree, while partial clone filters object transfer and may fetch missing objects later.” Apply this procedure: Measure working-tree files and object database separately; combine features only deliberately. The expected mechanism is: Repository-object size is evidence distinct from the sparse working-tree footprint. For the website repository, add one near-miss that exposes promising disk or network savings from sparsity alone without measuring repository objects. 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 promising disk or network savings from sparsity alone without measuring repository objects.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Measure working-tree files and object database separately; combine features only deliberately.” 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 school monorepo with one subject app, shared libraries and documentation. Include one ordinary case, one boundary and one deliberate failure caused by promising disk or network savings from sparsity alone without measuring repository objects. 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: Sparse checkout limits the working tree, while partial clone filters object transfer and may fetch missing objects later. It shows a trace, not only a final value. The ordinary case should demonstrate “Repository-object size is evidence distinct from the sparse working-tree footprint.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Measure working-tree files and object database separately; combine features only deliberately. 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 sparse index represents collapsed directory entries to improve some operations in large repositories, subject to command support and workflow needs. 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 enabling it as a magic speed flag without compatibility testing. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Benchmark the actual commands and keep a recovery route to a full index.
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 sparse-checkout init --cone --sparse-indexExplained result. The worktree uses cone sparsity and requests sparse-index behaviour. 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: school monorepo. Stress-test the rule using one subject app, shared libraries and documentation. 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 sparse index represents collapsed directory entries to improve some operations in large repositories, subject to command support and workflow needs.” Apply this procedure: Benchmark the actual commands and keep a recovery route to a full index. The expected mechanism is: The worktree uses cone sparsity and requests sparse-index behaviour. For the school monorepo, add one near-miss that exposes enabling it as a magic speed flag without compatibility testing. 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 repository. Explain the rule using content, theme, media tooling and deployment scripts. 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 sparse index represents collapsed directory entries to improve some operations in large repositories, subject to command support and workflow needs.” Apply this procedure: Benchmark the actual commands and keep a recovery route to a full index. The expected mechanism is: The worktree uses cone sparsity and requests sparse-index behaviour. For the website repository, add one near-miss that exposes enabling it as a magic speed flag without compatibility testing. 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 project. Transfer the rule using notebooks, source tables, generated output and tests. 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 sparse index represents collapsed directory entries to improve some operations in large repositories, subject to command support and workflow needs.” Apply this procedure: Benchmark the actual commands and keep a recovery route to a full index. The expected mechanism is: The worktree uses cone sparsity and requests sparse-index behaviour. For the data project, add one near-miss that exposes enabling it as a magic speed flag without compatibility testing. 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: coding CCA repo. Predict the rule using team folders, shared utilities and challenge 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 sparse index represents collapsed directory entries to improve some operations in large repositories, subject to command support and workflow needs.” Apply this procedure: Benchmark the actual commands and keep a recovery route to a full index. The expected mechanism is: The worktree uses cone sparsity and requests sparse-index behaviour. For the coding CCA repo, add one near-miss that exposes enabling it as a magic speed flag without compatibility testing. 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 enabling it as a magic speed flag without compatibility testing.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Benchmark the actual commands and keep a recovery route to a full index.” 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 repository with content, theme, media tooling and deployment scripts. Include one ordinary case, one boundary and one deliberate failure caused by enabling it as a magic speed flag without compatibility testing. 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 sparse index represents collapsed directory entries to improve some operations in large repositories, subject to command support and workflow needs. It shows a trace, not only a final value. The ordinary case should demonstrate “The worktree uses cone sparsity and requests sparse-index behaviour.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Benchmark the actual commands and keep a recovery route to a full index. 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
Switching branches changes the committed tree while sparse rules continue to determine which paths materialise. 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 every selected directory exists on every branch. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect branch contents, status and sparse list around the switch.
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 switch feature/reportingExplained result. The new commit is checked out through the current sparse specification. 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 project. Explain the rule using notebooks, source tables, generated output and tests. 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 “Switching branches changes the committed tree while sparse rules continue to determine which paths materialise.” Apply this procedure: Inspect branch contents, status and sparse list around the switch. The expected mechanism is: The new commit is checked out through the current sparse specification. For the data project, add one near-miss that exposes assuming every selected directory exists on every branch. 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: coding CCA repo. Transfer the rule using team folders, shared utilities and challenge 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 “Switching branches changes the committed tree while sparse rules continue to determine which paths materialise.” Apply this procedure: Inspect branch contents, status and sparse list around the switch. The expected mechanism is: The new commit is checked out through the current sparse specification. For the coding CCA repo, add one near-miss that exposes assuming every selected directory exists on every branch. 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: revision archive. Predict the rule using year folders, subject notes and common templates. 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 “Switching branches changes the committed tree while sparse rules continue to determine which paths materialise.” Apply this procedure: Inspect branch contents, status and sparse list around the switch. The expected mechanism is: The new commit is checked out through the current sparse specification. For the revision archive, add one near-miss that exposes assuming every selected directory exists on every branch. 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: mobile project. Contrast the rule using application, backend, packages and design assets. 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 “Switching branches changes the committed tree while sparse rules continue to determine which paths materialise.” Apply this procedure: Inspect branch contents, status and sparse list around the switch. The expected mechanism is: The new commit is checked out through the current sparse specification. For the mobile project, add one near-miss that exposes assuming every selected directory exists on every branch. 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 every selected directory exists on every branch.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect branch contents, status and sparse list around the switch.” 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 project with notebooks, source tables, generated output and tests. Include one ordinary case, one boundary and one deliberate failure caused by assuming every selected directory exists on every branch. 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: Switching branches changes the committed tree while sparse rules continue to determine which paths materialise. It shows a trace, not only a final value. The ordinary case should demonstrate “The new commit is checked out through the current sparse specification.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect branch contents, status and sparse list around the switch. 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
History operations can expose conflicts or paths outside the usual sparse view, and Git may vivify files so the user can resolve them. 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 deleting conflict files because they fall outside the normal sparse set. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Resolve the history operation first, verify status, then reapply sparsity.
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 --shortExplained result. Status identifies unmerged paths regardless of the learner’s usual directory focus. 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: revision archive. Transfer the rule using year folders, subject notes and common templates. 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 “History operations can expose conflicts or paths outside the usual sparse view, and Git may vivify files so the user can resolve them.” Apply this procedure: Resolve the history operation first, verify status, then reapply sparsity. The expected mechanism is: Status identifies unmerged paths regardless of the learner’s usual directory focus. For the revision archive, add one near-miss that exposes deleting conflict files because they fall outside the normal sparse set. 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: mobile project. Predict the rule using application, backend, packages and design assets. 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 “History operations can expose conflicts or paths outside the usual sparse view, and Git may vivify files so the user can resolve them.” Apply this procedure: Resolve the history operation first, verify status, then reapply sparsity. The expected mechanism is: Status identifies unmerged paths regardless of the learner’s usual directory focus. For the mobile project, add one near-miss that exposes deleting conflict files because they fall outside the normal sparse set. 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: documentation repo. Contrast the rule using guides, examples, localisation and build tools. 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 “History operations can expose conflicts or paths outside the usual sparse view, and Git may vivify files so the user can resolve them.” Apply this procedure: Resolve the history operation first, verify status, then reapply sparsity. The expected mechanism is: Status identifies unmerged paths regardless of the learner’s usual directory focus. For the documentation repo, add one near-miss that exposes deleting conflict files because they fall outside the normal sparse set. 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: recovery lab. Stress-test the rule using disposable branches, untracked files and sparse patterns. 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 “History operations can expose conflicts or paths outside the usual sparse view, and Git may vivify files so the user can resolve them.” Apply this procedure: Resolve the history operation first, verify status, then reapply sparsity. The expected mechanism is: Status identifies unmerged paths regardless of the learner’s usual directory focus. For the recovery lab, add one near-miss that exposes deleting conflict files because they fall outside the normal sparse set. 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 deleting conflict files because they fall outside the normal sparse set.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Resolve the history operation first, verify status, then reapply sparsity.” 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 CCA repo with team folders, shared utilities and challenge archives. Include one ordinary case, one boundary and one deliberate failure caused by deleting conflict files because they fall outside the normal sparse set. 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: History operations can expose conflicts or paths outside the usual sparse view, and Git may vivify files so the user can resolve them. It shows a trace, not only a final value. The ordinary case should demonstrate “Status identifies unmerged paths regardless of the learner’s usual directory focus.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Resolve the history operation first, verify status, then reapply sparsity. 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
Commands, tools or scripts can create or modify paths outside expected materialisation, and Git protects meaningful 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 forcing reapply or reset before preserving unexpected work. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect tracked, untracked and staged state and decide ownership explicitly.
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 --ignored --shortExplained result. The wider status view helps distinguish sparse, ignored and untracked effects. 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: documentation repo. Predict the rule using guides, examples, localisation and build tools. 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 “Commands, tools or scripts can create or modify paths outside expected materialisation, and Git protects meaningful changes.” Apply this procedure: Inspect tracked, untracked and staged state and decide ownership explicitly. The expected mechanism is: The wider status view helps distinguish sparse, ignored and untracked effects. For the documentation repo, add one near-miss that exposes forcing reapply or reset before preserving unexpected work. 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: recovery lab. Contrast the rule using disposable branches, untracked files and sparse patterns. 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 “Commands, tools or scripts can create or modify paths outside expected materialisation, and Git protects meaningful changes.” Apply this procedure: Inspect tracked, untracked and staged state and decide ownership explicitly. The expected mechanism is: The wider status view helps distinguish sparse, ignored and untracked effects. For the recovery lab, add one near-miss that exposes forcing reapply or reset before preserving unexpected work. 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: school monorepo. Stress-test the rule using one subject app, shared libraries and documentation. 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 “Commands, tools or scripts can create or modify paths outside expected materialisation, and Git protects meaningful changes.” Apply this procedure: Inspect tracked, untracked and staged state and decide ownership explicitly. The expected mechanism is: The wider status view helps distinguish sparse, ignored and untracked effects. For the school monorepo, add one near-miss that exposes forcing reapply or reset before preserving unexpected work. 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 repository. Explain the rule using content, theme, media tooling and deployment scripts. 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 “Commands, tools or scripts can create or modify paths outside expected materialisation, and Git protects meaningful changes.” Apply this procedure: Inspect tracked, untracked and staged state and decide ownership explicitly. The expected mechanism is: The wider status view helps distinguish sparse, ignored and untracked effects. For the website repository, add one near-miss that exposes forcing reapply or reset before preserving unexpected work. 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 forcing reapply or reset before preserving unexpected work.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect tracked, untracked and staged state and decide ownership explicitly.” 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 revision archive with year folders, subject notes and common templates. Include one ordinary case, one boundary and one deliberate failure caused by forcing reapply or reset before preserving unexpected work. 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: Commands, tools or scripts can create or modify paths outside expected materialisation, and Git protects meaningful changes. It shows a trace, not only a final value. The ordinary case should demonstrate “The wider status view helps distinguish sparse, ignored and untracked effects.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect tracked, untracked and staged state and decide ownership explicitly. 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 sparse view can make it easy to forget changes produced elsewhere, so the staged diff and commit tree remain essential review surfaces. 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 reviewing only visible directories before committing. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use diff –cached and name-status to inspect the whole proposed commit.
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 diff --cached --name-statusExplained result. The staged change list reveals paths whether or not they are currently prominent in the worktree. 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: school monorepo. Contrast the rule using one subject app, shared libraries and documentation. 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 sparse view can make it easy to forget changes produced elsewhere, so the staged diff and commit tree remain essential review surfaces.” Apply this procedure: Use diff –cached and name-status to inspect the whole proposed commit. The expected mechanism is: The staged change list reveals paths whether or not they are currently prominent in the worktree. For the school monorepo, add one near-miss that exposes reviewing only visible directories before committing. 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 repository. Stress-test the rule using content, theme, media tooling and deployment scripts. 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 sparse view can make it easy to forget changes produced elsewhere, so the staged diff and commit tree remain essential review surfaces.” Apply this procedure: Use diff –cached and name-status to inspect the whole proposed commit. The expected mechanism is: The staged change list reveals paths whether or not they are currently prominent in the worktree. For the website repository, add one near-miss that exposes reviewing only visible directories before committing. 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 project. Explain the rule using notebooks, source tables, generated output and tests. 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 sparse view can make it easy to forget changes produced elsewhere, so the staged diff and commit tree remain essential review surfaces.” Apply this procedure: Use diff –cached and name-status to inspect the whole proposed commit. The expected mechanism is: The staged change list reveals paths whether or not they are currently prominent in the worktree. For the data project, add one near-miss that exposes reviewing only visible directories before committing. 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: coding CCA repo. Transfer the rule using team folders, shared utilities and challenge 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 sparse view can make it easy to forget changes produced elsewhere, so the staged diff and commit tree remain essential review surfaces.” Apply this procedure: Use diff –cached and name-status to inspect the whole proposed commit. The expected mechanism is: The staged change list reveals paths whether or not they are currently prominent in the worktree. For the coding CCA repo, add one near-miss that exposes reviewing only visible directories before committing. 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 reviewing only visible directories before committing.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use diff –cached and name-status to inspect the whole proposed commit.” 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 mobile project with application, backend, packages and design assets. Include one ordinary case, one boundary and one deliberate failure caused by reviewing only visible directories before committing. 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 sparse view can make it easy to forget changes produced elsewhere, so the staged diff and commit tree remain essential review surfaces. It shows a trace, not only a final value. The ordinary case should demonstrate “The staged change list reveals paths whether or not they are currently prominent in the worktree.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use diff –cached and name-status to inspect the whole proposed commit. 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
Sparse-checkout configuration can be worktree-specific, allowing linked worktrees to materialise different directory sets. 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 a sparse change in one worktree automatically defines every linked worktree. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Run list inside each worktree and label terminal paths clearly.
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 -C ../docs-tree sparse-checkout listExplained result. The command reads the sparse specification for that linked worktree. 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 project. Stress-test the rule using notebooks, source tables, generated output and tests. 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 “Sparse-checkout configuration can be worktree-specific, allowing linked worktrees to materialise different directory sets.” Apply this procedure: Run list inside each worktree and label terminal paths clearly. The expected mechanism is: The command reads the sparse specification for that linked worktree. For the data project, add one near-miss that exposes assuming a sparse change in one worktree automatically defines every linked worktree. 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: coding CCA repo. Explain the rule using team folders, shared utilities and challenge 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 “Sparse-checkout configuration can be worktree-specific, allowing linked worktrees to materialise different directory sets.” Apply this procedure: Run list inside each worktree and label terminal paths clearly. The expected mechanism is: The command reads the sparse specification for that linked worktree. For the coding CCA repo, add one near-miss that exposes assuming a sparse change in one worktree automatically defines every linked worktree. 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: revision archive. Transfer the rule using year folders, subject notes and common templates. 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 “Sparse-checkout configuration can be worktree-specific, allowing linked worktrees to materialise different directory sets.” Apply this procedure: Run list inside each worktree and label terminal paths clearly. The expected mechanism is: The command reads the sparse specification for that linked worktree. For the revision archive, add one near-miss that exposes assuming a sparse change in one worktree automatically defines every linked worktree. 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: mobile project. Predict the rule using application, backend, packages and design assets. 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 “Sparse-checkout configuration can be worktree-specific, allowing linked worktrees to materialise different directory sets.” Apply this procedure: Run list inside each worktree and label terminal paths clearly. The expected mechanism is: The command reads the sparse specification for that linked worktree. For the mobile project, add one near-miss that exposes assuming a sparse change in one worktree automatically defines every linked worktree. 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 a sparse change in one worktree automatically defines every linked worktree.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Run list inside each worktree and label terminal paths clearly.” 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 repo with guides, examples, localisation and build tools. Include one ordinary case, one boundary and one deliberate failure caused by assuming a sparse change in one worktree automatically defines every linked worktree. 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: Sparse-checkout configuration can be worktree-specific, allowing linked worktrees to materialise different directory sets. It shows a trace, not only a final value. The ordinary case should demonstrate “The command reads the sparse specification for that linked worktree.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Run list inside each worktree and label terminal paths clearly. 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 submodule is its own repository and working tree; superproject sparsity does not become a universal recursive submodule policy. 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 sparse patterns to configure submodule contents automatically. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Document superproject selection and each submodule workflow 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
git submodule statusExplained result. The command reports submodule commits but not a shared sparse policy. 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: revision archive. Explain the rule using year folders, subject notes and common templates. 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 submodule is its own repository and working tree; superproject sparsity does not become a universal recursive submodule policy.” Apply this procedure: Document superproject selection and each submodule workflow separately. The expected mechanism is: The command reports submodule commits but not a shared sparse policy. For the revision archive, add one near-miss that exposes expecting sparse patterns to configure submodule contents 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: mobile project. Transfer the rule using application, backend, packages and design assets. 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 submodule is its own repository and working tree; superproject sparsity does not become a universal recursive submodule policy.” Apply this procedure: Document superproject selection and each submodule workflow separately. The expected mechanism is: The command reports submodule commits but not a shared sparse policy. For the mobile project, add one near-miss that exposes expecting sparse patterns to configure submodule contents 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: documentation repo. Predict the rule using guides, examples, localisation and build tools. 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 submodule is its own repository and working tree; superproject sparsity does not become a universal recursive submodule policy.” Apply this procedure: Document superproject selection and each submodule workflow separately. The expected mechanism is: The command reports submodule commits but not a shared sparse policy. For the documentation repo, add one near-miss that exposes expecting sparse patterns to configure submodule contents 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: recovery lab. Contrast the rule using disposable branches, untracked files and sparse patterns. 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 submodule is its own repository and working tree; superproject sparsity does not become a universal recursive submodule policy.” Apply this procedure: Document superproject selection and each submodule workflow separately. The expected mechanism is: The command reports submodule commits but not a shared sparse policy. For the recovery lab, add one near-miss that exposes expecting sparse patterns to configure submodule contents 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 expecting sparse patterns to configure submodule contents automatically.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Document superproject selection and each submodule workflow 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 recovery lab with disposable branches, untracked files and sparse patterns. Include one ordinary case, one boundary and one deliberate failure caused by expecting sparse patterns to configure submodule contents 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: A submodule is its own repository and working tree; superproject sparsity does not become a universal recursive submodule policy. It shows a trace, not only a final value. The ordinary case should demonstrate “The command reports submodule commits but not a shared sparse policy.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Document superproject selection and each submodule workflow 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
Mastery means predicting what remains in history, index and disk, protecting changes, and recovering to a full checkout. 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 memorising set and add without practising branch, conflict and disable paths. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Build a disposable repository, enable cone mode, change selections, switch branch, reapply and disable while recording state.
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 sparse-checkout disableExplained result. A clean full checkout and explainable history/index/worktree model complete the rehearsal. 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: documentation repo. Transfer the rule using guides, examples, localisation and build tools. 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 “Mastery means predicting what remains in history, index and disk, protecting changes, and recovering to a full checkout.” Apply this procedure: Build a disposable repository, enable cone mode, change selections, switch branch, reapply and disable while recording state. The expected mechanism is: A clean full checkout and explainable history/index/worktree model complete the rehearsal. For the documentation repo, add one near-miss that exposes memorising set and add without practising branch, conflict and disable paths. 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: recovery lab. Predict the rule using disposable branches, untracked files and sparse patterns. 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 “Mastery means predicting what remains in history, index and disk, protecting changes, and recovering to a full checkout.” Apply this procedure: Build a disposable repository, enable cone mode, change selections, switch branch, reapply and disable while recording state. The expected mechanism is: A clean full checkout and explainable history/index/worktree model complete the rehearsal. For the recovery lab, add one near-miss that exposes memorising set and add without practising branch, conflict and disable paths. 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: school monorepo. Contrast the rule using one subject app, shared libraries and documentation. 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 “Mastery means predicting what remains in history, index and disk, protecting changes, and recovering to a full checkout.” Apply this procedure: Build a disposable repository, enable cone mode, change selections, switch branch, reapply and disable while recording state. The expected mechanism is: A clean full checkout and explainable history/index/worktree model complete the rehearsal. For the school monorepo, add one near-miss that exposes memorising set and add without practising branch, conflict and disable paths. 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 repository. Stress-test the rule using content, theme, media tooling and deployment scripts. 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 “Mastery means predicting what remains in history, index and disk, protecting changes, and recovering to a full checkout.” Apply this procedure: Build a disposable repository, enable cone mode, change selections, switch branch, reapply and disable while recording state. The expected mechanism is: A clean full checkout and explainable history/index/worktree model complete the rehearsal. For the website repository, add one near-miss that exposes memorising set and add without practising branch, conflict and disable paths. 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 memorising set and add without practising branch, conflict and disable paths.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Build a disposable repository, enable cone mode, change selections, switch branch, reapply and disable while recording state.” 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 school monorepo with one subject app, shared libraries and documentation. Include one ordinary case, one boundary and one deliberate failure caused by memorising set and add without practising branch, conflict and disable paths. 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: Mastery means predicting what remains in history, index and disk, protecting changes, and recovering to a full checkout. It shows a trace, not only a final value. The ordinary case should demonstrate “A clean full checkout and explainable history/index/worktree model complete the rehearsal.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Build a disposable repository, enable cone mode, change selections, switch branch, reapply and disable while recording state. 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. school monorepo: model, boundary and recovery
Create a small school monorepo using one subject app, shared libraries and documentation. Combine “The sparse working-tree model” 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: Sparse checkout changes which tracked paths are present in one working tree while commits and repository history still describe the complete tree. Apply: Draw history, index and working tree as separate layers before running a command. Verify: The command reports sparse path rules, not a list of objects downloaded from history. 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. website repository: model, boundary and recovery
Create a small website repository using content, theme, media tooling and deployment scripts. Combine “Initialising sparse checkout” 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: init enables sparse-checkout configuration for the current worktree and establishes an initial mode, though set can perform necessary setup in modern workflows. Apply: Record pwd, branch and git worktree list before enabling sparsity. Verify: The current worktree enters cone-mode sparse operation. 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 project: model, boundary and recovery
Create a small data project using notebooks, source tables, generated output and tests. Combine “list reports the current rules” 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: list provides the selected sparse paths in the user-facing specification. Apply: Compare sparse rules with git status and tracked files. Verify: The output states the current sparse selection independently of incidental files on disk. 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. coding CCA repo: model, boundary and recovery
Create a small coding CCA repo using team folders, shared utilities and challenge archives. Combine “skip-worktree is an implementation detail” 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: Sparse checkout uses skip-worktree index bits, but users should manage the feature with sparse-checkout commands rather than toggling bits casually. Apply: Use plumbing observations only for diagnosis and keep the porcelain specification authoritative. Verify: The diagnostic output can reveal index flags but is not the workflow interface. 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. revision archive: model, boundary and recovery
Create a small revision archive using year folders, subject notes and common templates. Combine “Sparse index can reduce index work” 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: A sparse index represents collapsed directory entries to improve some operations in large repositories, subject to command support and workflow needs. Apply: Benchmark the actual commands and keep a recovery route to a full index. Verify: The worktree uses cone sparsity and requests sparse-index behaviour. 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. mobile project: model, boundary and recovery
Create a small mobile project using application, backend, packages and design assets. Combine “Changes outside the sparse set” 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: Commands, tools or scripts can create or modify paths outside expected materialisation, and Git protects meaningful changes. Apply: Inspect tracked, untracked and staged state and decide ownership explicitly. Verify: The wider status view helps distinguish sparse, ignored and untracked effects. 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. documentation repo: model, boundary and recovery
Create a small documentation repo using guides, examples, localisation and build tools. Combine “Submodules have separate repositories” 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: A submodule is its own repository and working tree; superproject sparsity does not become a universal recursive submodule policy. Apply: Document superproject selection and each submodule workflow separately. Verify: The command reports submodule commits but not a shared sparse policy. 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. recovery lab: model, boundary and recovery
Create a small recovery lab using disposable branches, untracked files and sparse patterns. Combine “Cone mode and directory thinking” 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: Cone mode uses directory-oriented patterns and is the recommended efficient model for common monorepo workflows. Apply: Choose directories as ownership units or explicitly justify non-cone mode. Verify: The working tree focuses on the selected directories plus required parent files. 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.
