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 rerere means reuse recorded resolution: Git can remember how a particular textual conflict was resolved and apply that recorded resolution when the same conflict shape appears again. Mastery means enabling it deliberately, understanding preimage and postimage records, reviewing reused results rather than trusting them blindly, and knowing how to forget, clear, share or disable the mechanism safely. 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
rerere observes conflicted file preimages, records the human resolution and can reuse it when an equivalent conflict appears 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 describing rerere as automatically deciding which branch is correct. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result.
For the Reuse recorded resolution chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on describing rerere as automatically deciding which branch is correct. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git config rerere.enabled true
git merge topicExplained result. Git records the conflict shape; after the file is resolved and staged, it can learn the resolution for a future match. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Predict the rule using a feature branch repeatedly rebased over a changing main branch. 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 “rerere observes conflicted file preimages, records the human resolution and can reuse it when an equivalent conflict appears later.” Apply this procedure: Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result. The expected mechanism is: Git records the conflict shape; after the file is resolved and staged, it can learn the resolution for a future match. For the coding project, add one near-miss that exposes describing rerere as automatically deciding which branch is correct. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Contrast the rule using two classmates editing the same report paragraph. 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 “rerere observes conflicted file preimages, records the human resolution and can reuse it when an equivalent conflict appears later.” Apply this procedure: Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result. The expected mechanism is: Git records the conflict shape; after the file is resolved and staged, it can learn the resolution for a future match. For the group assignment, add one near-miss that exposes describing rerere as automatically deciding which branch is correct. 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: website project. Stress-test the rule using parallel CSS changes meeting in one component. 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 “rerere observes conflicted file preimages, records the human resolution and can reuse it when an equivalent conflict appears later.” Apply this procedure: Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result. The expected mechanism is: Git records the conflict shape; after the file is resolved and staged, it can learn the resolution for a future match. For the website project, add one near-miss that exposes describing rerere as automatically deciding which branch is correct. 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: science notes. Explain the rule using a recurring conflict in a shared results table. 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 “rerere observes conflicted file preimages, records the human resolution and can reuse it when an equivalent conflict appears later.” Apply this procedure: Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result. The expected mechanism is: Git records the conflict shape; after the file is resolved and staged, it can learn the resolution for a future match. For the science notes, add one near-miss that exposes describing rerere as automatically deciding which branch is correct. 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 describing rerere as automatically deciding which branch is correct.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Reuse recorded resolution?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing describing rerere as automatically deciding which branch is correct be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny documentation release with a long-lived fix merged into several release branches. Include one ordinary case, one boundary and one deliberate failure caused by describing rerere as automatically deciding which branch is correct. 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: rerere observes conflicted file preimages, records the human resolution and can reuse it when an equivalent conflict appears later. It shows a trace, not only a final value. The ordinary case should demonstrate “Git records the conflict shape; after the file is resolved and staged, it can learn the resolution for a future match.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Reuse recorded resolution, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
rerere.enabled can be set in one repository or globally, and an rr-cache directory can also make the facility active in documented configurations. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is changing global policy during one experiment and surprising every repository. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow.
For the Enable locally or globally with intent chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on changing global policy during one experiment and surprising every repository. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git config --local rerere.enabled true
git config --get rerere.enabledExplained result. The repository now records and reuses eligible resolutions without changing unrelated repositories. 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: website project. Contrast the rule using parallel CSS changes meeting in one component. 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 “rerere.enabled can be set in one repository or globally, and an rr-cache directory can also make the facility active in documented configurations.” Apply this procedure: Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow. The expected mechanism is: The repository now records and reuses eligible resolutions without changing unrelated repositories. For the website project, add one near-miss that exposes changing global policy during one experiment and surprising every repository. 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: science notes. Stress-test the rule using a recurring conflict in a shared results table. 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 “rerere.enabled can be set in one repository or globally, and an rr-cache directory can also make the facility active in documented configurations.” Apply this procedure: Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow. The expected mechanism is: The repository now records and reuses eligible resolutions without changing unrelated repositories. For the science notes, add one near-miss that exposes changing global policy during one experiment and surprising every repository. 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 repository. Explain the rule using topic lists reordered on two branches. 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 “rerere.enabled can be set in one repository or globally, and an rr-cache directory can also make the facility active in documented configurations.” Apply this procedure: Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow. The expected mechanism is: The repository now records and reuses eligible resolutions without changing unrelated repositories. For the revision repository, add one near-miss that exposes changing global policy during one experiment and surprising every repository. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Transfer the rule using a long-lived fix merged into several release branches. 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 “rerere.enabled can be set in one repository or globally, and an rr-cache directory can also make the facility active in documented configurations.” Apply this procedure: Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow. The expected mechanism is: The repository now records and reuses eligible resolutions without changing unrelated repositories. For the documentation release, add one near-miss that exposes changing global policy during one experiment and surprising every repository. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers changing global policy during one experiment and surprising every repository.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Enable locally or globally with intent?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing changing global policy during one experiment and surprising every repository be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny worktree lab with two linked worktrees rehearsing the same integration. Include one ordinary case, one boundary and one deliberate failure caused by changing global policy during one experiment and surprising every repository. 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: rerere.enabled can be set in one repository or globally, and an rr-cache directory can also make the facility active in documented configurations. It shows a trace, not only a final value. The ordinary case should demonstrate “The repository now records and reuses eligible resolutions without changing unrelated repositories.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Enable locally or globally with intent, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Git stores a canonicalised conflicted preimage so equivalent marker arrangements can be recognised across repeated integrations. 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 the cache key is a filename or commit hash. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect rr-cache after conflict and compare conflict content rather than path names alone.
For the Conflict preimages are canonical records chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming the cache key is a filename or commit hash. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
find .git/rr-cache -maxdepth 2 -type f -printExplained result. The cache directory contains per-conflict records such as preimage and, after learning, postimage. 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 repository. Stress-test the rule using topic lists reordered on two branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git stores a canonicalised conflicted preimage so equivalent marker arrangements can be recognised across repeated integrations.” Apply this procedure: Inspect rr-cache after conflict and compare conflict content rather than path names alone. The expected mechanism is: The cache directory contains per-conflict records such as preimage and, after learning, postimage. For the revision repository, add one near-miss that exposes assuming the cache key is a filename or commit hash. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Explain the rule using a long-lived fix merged into several release branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git stores a canonicalised conflicted preimage so equivalent marker arrangements can be recognised across repeated integrations.” Apply this procedure: Inspect rr-cache after conflict and compare conflict content rather than path names alone. The expected mechanism is: The cache directory contains per-conflict records such as preimage and, after learning, postimage. For the documentation release, add one near-miss that exposes assuming the cache key is a filename or commit hash. 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: worktree lab. Transfer the rule using two linked worktrees rehearsing the same integration. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git stores a canonicalised conflicted preimage so equivalent marker arrangements can be recognised across repeated integrations.” Apply this procedure: Inspect rr-cache after conflict and compare conflict content rather than path names alone. The expected mechanism is: The cache directory contains per-conflict records such as preimage and, after learning, postimage. For the worktree lab, add one near-miss that exposes assuming the cache key is a filename or commit hash. 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: debug repository. Predict the rule using a disposable three-commit history with one reproducible conflict. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Git stores a canonicalised conflicted preimage so equivalent marker arrangements can be recognised across repeated integrations.” Apply this procedure: Inspect rr-cache after conflict and compare conflict content rather than path names alone. The expected mechanism is: The cache directory contains per-conflict records such as preimage and, after learning, postimage. For the debug repository, add one near-miss that exposes assuming the cache key is a filename or commit hash. 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 the cache key is a filename or commit hash.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect rr-cache after conflict and compare conflict content rather than path names alone.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Conflict preimages are canonical records?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the cache key is a filename or commit hash be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny debug repository with a disposable three-commit history with one reproducible conflict. Include one ordinary case, one boundary and one deliberate failure caused by assuming the cache key is a filename or commit hash. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Git stores a canonicalised conflicted preimage so equivalent marker arrangements can be recognised across repeated integrations. It shows a trace, not only a final value. The ordinary case should demonstrate “The cache directory contains per-conflict records such as preimage and, after learning, postimage.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect rr-cache after conflict and compare conflict content rather than path names alone. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Conflict preimages are canonical records, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
After the user resolves and stages the conflicted path, rerere records the resolved file as a postimage associated with the preimage. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is editing a file but never staging it, then expecting the resolution to be learned. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Resolve markers, review the file and use git add so Git can observe completion.
For the Postimages capture the resolved content chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on editing a file but never staging it, then expecting the resolution to be learned. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git add report.txt
git rerere statusExplained result. Staging marks the conflict resolved, allowing the resolved content to be recorded for reuse. 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: worktree lab. Explain the rule using two linked worktrees rehearsing the same integration. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After the user resolves and stages the conflicted path, rerere records the resolved file as a postimage associated with the preimage.” Apply this procedure: Resolve markers, review the file and use git add so Git can observe completion. The expected mechanism is: Staging marks the conflict resolved, allowing the resolved content to be recorded for reuse. For the worktree lab, add one near-miss that exposes editing a file but never staging it, then expecting the resolution to be learned. 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: debug repository. Transfer the rule using a disposable three-commit history with one reproducible conflict. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After the user resolves and stages the conflicted path, rerere records the resolved file as a postimage associated with the preimage.” Apply this procedure: Resolve markers, review the file and use git add so Git can observe completion. The expected mechanism is: Staging marks the conflict resolved, allowing the resolved content to be recorded for reuse. For the debug repository, add one near-miss that exposes editing a file but never staging it, then expecting the resolution to be learned. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Predict the rule using a feature branch repeatedly rebased over a changing main branch. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After the user resolves and stages the conflicted path, rerere records the resolved file as a postimage associated with the preimage.” Apply this procedure: Resolve markers, review the file and use git add so Git can observe completion. The expected mechanism is: Staging marks the conflict resolved, allowing the resolved content to be recorded for reuse. For the coding project, add one near-miss that exposes editing a file but never staging it, then expecting the resolution to be learned. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Contrast the rule using two classmates editing the same report paragraph. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “After the user resolves and stages the conflicted path, rerere records the resolved file as a postimage associated with the preimage.” Apply this procedure: Resolve markers, review the file and use git add so Git can observe completion. The expected mechanism is: Staging marks the conflict resolved, allowing the resolved content to be recorded for reuse. For the group assignment, add one near-miss that exposes editing a file but never staging it, then expecting the resolution to be learned. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers editing a file but never staging it, then expecting the resolution to be learned.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Resolve markers, review the file and use git add so Git can observe completion.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Postimages capture the resolved content?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing editing a file but never staging it, then expecting the resolution to be learned be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny coding project with a feature branch repeatedly rebased over a changing main branch. Include one ordinary case, one boundary and one deliberate failure caused by editing a file but never staging it, then expecting the resolution to be learned. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: After the user resolves and stages the conflicted path, rerere records the resolved file as a postimage associated with the preimage. It shows a trace, not only a final value. The ordinary case should demonstrate “Staging marks the conflict resolved, allowing the resolved content to be recorded for reuse.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Resolve markers, review the file and use git add so Git can observe completion. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Postimages capture the resolved content, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
When enabled, Git invokes rerere around commands that create or resolve conflicts, so users often do not need to run git rerere manually. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is believing rerere is inactive because no explicit rerere command was typed. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Check configuration, messages, status and rr-cache evidence after a merge or rebase conflict.
For the Automatic observation during Git operations chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on believing rerere is inactive because no explicit rerere command was typed. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git merge feature
git status --shortExplained result. The history command creates the conflict and the enabled facility records eligible preimages automatically. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Transfer the rule using a feature branch repeatedly rebased over a changing main branch. 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 “When enabled, Git invokes rerere around commands that create or resolve conflicts, so users often do not need to run git rerere manually.” Apply this procedure: Check configuration, messages, status and rr-cache evidence after a merge or rebase conflict. The expected mechanism is: The history command creates the conflict and the enabled facility records eligible preimages automatically. For the coding project, add one near-miss that exposes believing rerere is inactive because no explicit rerere command was typed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Predict the rule using two classmates editing the same report paragraph. 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 “When enabled, Git invokes rerere around commands that create or resolve conflicts, so users often do not need to run git rerere manually.” Apply this procedure: Check configuration, messages, status and rr-cache evidence after a merge or rebase conflict. The expected mechanism is: The history command creates the conflict and the enabled facility records eligible preimages automatically. For the group assignment, add one near-miss that exposes believing rerere is inactive because no explicit rerere command was typed. 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: website project. Contrast the rule using parallel CSS changes meeting in one component. 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 “When enabled, Git invokes rerere around commands that create or resolve conflicts, so users often do not need to run git rerere manually.” Apply this procedure: Check configuration, messages, status and rr-cache evidence after a merge or rebase conflict. The expected mechanism is: The history command creates the conflict and the enabled facility records eligible preimages automatically. For the website project, add one near-miss that exposes believing rerere is inactive because no explicit rerere command was typed. 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: science notes. Stress-test the rule using a recurring conflict in a shared results table. 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 “When enabled, Git invokes rerere around commands that create or resolve conflicts, so users often do not need to run git rerere manually.” Apply this procedure: Check configuration, messages, status and rr-cache evidence after a merge or rebase conflict. The expected mechanism is: The history command creates the conflict and the enabled facility records eligible preimages automatically. For the science notes, add one near-miss that exposes believing rerere is inactive because no explicit rerere command was typed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers believing rerere is inactive because no explicit rerere command was typed.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Check configuration, messages, status and rr-cache evidence after a merge or rebase conflict.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Automatic observation during Git operations?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing believing rerere is inactive because no explicit rerere command was typed be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny group assignment with two classmates editing the same report paragraph. Include one ordinary case, one boundary and one deliberate failure caused by believing rerere is inactive because no explicit rerere command was typed. 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: When enabled, Git invokes rerere around commands that create or resolve conflicts, so users often do not need to run git rerere manually. It shows a trace, not only a final value. The ordinary case should demonstrate “The history command creates the conflict and the enabled facility records eligible preimages automatically.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Check configuration, messages, status and rr-cache evidence after a merge or rebase conflict. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Automatic observation during Git operations, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
The status subcommand reports paths with conflicts whose resolutions rerere is tracking. 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 confusing rerere status with the repository-wide index status. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use git status for all repository state and git rerere status for the rerere subset.
For the git rerere status lists tracked conflicts chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on confusing rerere status with the repository-wide index status. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git status --short
git rerere statusExplained result. The two views answer different questions and should be read together during resolution. 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: website project. Predict the rule using parallel CSS changes meeting in one component. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The status subcommand reports paths with conflicts whose resolutions rerere is tracking.” Apply this procedure: Use git status for all repository state and git rerere status for the rerere subset. The expected mechanism is: The two views answer different questions and should be read together during resolution. For the website project, add one near-miss that exposes confusing rerere status with the repository-wide index status. 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: science notes. Contrast the rule using a recurring conflict in a shared results table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The status subcommand reports paths with conflicts whose resolutions rerere is tracking.” Apply this procedure: Use git status for all repository state and git rerere status for the rerere subset. The expected mechanism is: The two views answer different questions and should be read together during resolution. For the science notes, add one near-miss that exposes confusing rerere status with the repository-wide index status. 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 repository. Stress-test the rule using topic lists reordered on two branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The status subcommand reports paths with conflicts whose resolutions rerere is tracking.” Apply this procedure: Use git status for all repository state and git rerere status for the rerere subset. The expected mechanism is: The two views answer different questions and should be read together during resolution. For the revision repository, add one near-miss that exposes confusing rerere status with the repository-wide index status. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Explain the rule using a long-lived fix merged into several release branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The status subcommand reports paths with conflicts whose resolutions rerere is tracking.” Apply this procedure: Use git status for all repository state and git rerere status for the rerere subset. The expected mechanism is: The two views answer different questions and should be read together during resolution. For the documentation release, add one near-miss that exposes confusing rerere status with the repository-wide index status. 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 confusing rerere status with the repository-wide index status.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use git status for all repository state and git rerere status for the rerere subset.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from git rerere status lists tracked conflicts?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing confusing rerere status with the repository-wide index status be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny website project with parallel CSS changes meeting in one component. Include one ordinary case, one boundary and one deliberate failure caused by confusing rerere status with the repository-wide index status. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The status subcommand reports paths with conflicts whose resolutions rerere is tracking. It shows a trace, not only a final value. The ordinary case should demonstrate “The two views answer different questions and should be read together during resolution.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use git status for all repository state and git rerere status for the rerere subset. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For git rerere status lists tracked conflicts, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
rerere diff displays differences between the conflict preimage and the current working resolution, helping review what was changed. 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 the final file and missing accidental edits outside the conflict. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect rerere diff, ordinary diff and staged diff before continuing the history operation.
For the git rerere diff shows resolution progress chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reviewing only the final file and missing accidental edits outside the conflict. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rerere diff
git diff --checkExplained result. The first focuses on recorded conflict resolution progress; the second catches whitespace errors in unstaged changes. 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 repository. Contrast the rule using topic lists reordered on two branches. 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 “rerere diff displays differences between the conflict preimage and the current working resolution, helping review what was changed.” Apply this procedure: Inspect rerere diff, ordinary diff and staged diff before continuing the history operation. The expected mechanism is: The first focuses on recorded conflict resolution progress; the second catches whitespace errors in unstaged changes. For the revision repository, add one near-miss that exposes reviewing only the final file and missing accidental edits outside the conflict. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Stress-test the rule using a long-lived fix merged into several release branches. 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 “rerere diff displays differences between the conflict preimage and the current working resolution, helping review what was changed.” Apply this procedure: Inspect rerere diff, ordinary diff and staged diff before continuing the history operation. The expected mechanism is: The first focuses on recorded conflict resolution progress; the second catches whitespace errors in unstaged changes. For the documentation release, add one near-miss that exposes reviewing only the final file and missing accidental edits outside the conflict. 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: worktree lab. Explain the rule using two linked worktrees rehearsing the same integration. 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 “rerere diff displays differences between the conflict preimage and the current working resolution, helping review what was changed.” Apply this procedure: Inspect rerere diff, ordinary diff and staged diff before continuing the history operation. The expected mechanism is: The first focuses on recorded conflict resolution progress; the second catches whitespace errors in unstaged changes. For the worktree lab, add one near-miss that exposes reviewing only the final file and missing accidental edits outside the conflict. 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: debug repository. Transfer the rule using a disposable three-commit history with one reproducible conflict. 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 “rerere diff displays differences between the conflict preimage and the current working resolution, helping review what was changed.” Apply this procedure: Inspect rerere diff, ordinary diff and staged diff before continuing the history operation. The expected mechanism is: The first focuses on recorded conflict resolution progress; the second catches whitespace errors in unstaged changes. For the debug repository, add one near-miss that exposes reviewing only the final file and missing accidental edits outside the conflict. 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 the final file and missing accidental edits outside the conflict.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect rerere diff, ordinary diff and staged diff before continuing the history operation.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from git rerere diff shows resolution progress?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reviewing only the final file and missing accidental edits outside the conflict be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science notes with a recurring conflict in a shared results table. Include one ordinary case, one boundary and one deliberate failure caused by reviewing only the final file and missing accidental edits outside the conflict. 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: rerere diff displays differences between the conflict preimage and the current working resolution, helping review what was changed. It shows a trace, not only a final value. The ordinary case should demonstrate “The first focuses on recorded conflict resolution progress; the second catches whitespace errors in unstaged changes.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect rerere diff, ordinary diff and staged diff before continuing the history operation. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For git rerere diff shows resolution progress, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 8 OF 20 . Use the core tools
8. git rerere remaining identifies unresolved paths
remaining prints paths with recorded preimages that have not yet reached a resolved state. 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 clean-looking editor means every index conflict is complete. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare remaining output with unmerged index entries and status.
For the git rerere remaining identifies unresolved paths chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming a clean-looking editor means every index conflict is complete. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rerere remaining
git ls-files -uExplained result. An empty remaining list is useful evidence, while ls-files -u confirms whether unmerged stages still exist. 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: worktree lab. Stress-test the rule using two linked worktrees rehearsing the same integration. 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 “remaining prints paths with recorded preimages that have not yet reached a resolved state.” Apply this procedure: Compare remaining output with unmerged index entries and status. The expected mechanism is: An empty remaining list is useful evidence, while ls-files -u confirms whether unmerged stages still exist. For the worktree lab, add one near-miss that exposes assuming a clean-looking editor means every index conflict is complete. 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: debug repository. Explain the rule using a disposable three-commit history with one reproducible conflict. 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 “remaining prints paths with recorded preimages that have not yet reached a resolved state.” Apply this procedure: Compare remaining output with unmerged index entries and status. The expected mechanism is: An empty remaining list is useful evidence, while ls-files -u confirms whether unmerged stages still exist. For the debug repository, add one near-miss that exposes assuming a clean-looking editor means every index conflict is complete. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Transfer the rule using a feature branch repeatedly rebased over a changing main branch. 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 “remaining prints paths with recorded preimages that have not yet reached a resolved state.” Apply this procedure: Compare remaining output with unmerged index entries and status. The expected mechanism is: An empty remaining list is useful evidence, while ls-files -u confirms whether unmerged stages still exist. For the coding project, add one near-miss that exposes assuming a clean-looking editor means every index conflict is complete. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Predict the rule using two classmates editing the same report paragraph. 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 “remaining prints paths with recorded preimages that have not yet reached a resolved state.” Apply this procedure: Compare remaining output with unmerged index entries and status. The expected mechanism is: An empty remaining list is useful evidence, while ls-files -u confirms whether unmerged stages still exist. For the group assignment, add one near-miss that exposes assuming a clean-looking editor means every index conflict is complete. 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 clean-looking editor means every index conflict is complete.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Compare remaining output with unmerged index entries and status.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from git rerere remaining identifies unresolved paths?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming a clean-looking editor means every index conflict is complete be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision repository with topic lists reordered on two branches. Include one ordinary case, one boundary and one deliberate failure caused by assuming a clean-looking editor means every index conflict is complete. 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: remaining prints paths with recorded preimages that have not yet reached a resolved state. It shows a trace, not only a final value. The ordinary case should demonstrate “An empty remaining list is useful evidence, while ls-files -u confirms whether unmerged stages still exist.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Compare remaining output with unmerged index entries and status. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For git rerere remaining identifies unresolved paths, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
When a recorded resolution matches, rerere can update the conflicted file in the working tree while leaving review and staging to the user. 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 reused file is automatically accepted and committed. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Read the reuse message, diff the file and stage only after semantic review.
For the Reuse edits the working tree by default chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming a reused file is automatically accepted and committed. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git merge topic
git diffExplained result. The working tree may already contain the prior resolution, but the user still checks whether it fits the current context. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Explain the rule using a feature branch repeatedly rebased over a changing main branch. 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 “When a recorded resolution matches, rerere can update the conflicted file in the working tree while leaving review and staging to the user.” Apply this procedure: Read the reuse message, diff the file and stage only after semantic review. The expected mechanism is: The working tree may already contain the prior resolution, but the user still checks whether it fits the current context. For the coding project, add one near-miss that exposes assuming a reused file is automatically accepted and committed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Transfer the rule using two classmates editing the same report paragraph. 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 “When a recorded resolution matches, rerere can update the conflicted file in the working tree while leaving review and staging to the user.” Apply this procedure: Read the reuse message, diff the file and stage only after semantic review. The expected mechanism is: The working tree may already contain the prior resolution, but the user still checks whether it fits the current context. For the group assignment, add one near-miss that exposes assuming a reused file is automatically accepted and committed. 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: website project. Predict the rule using parallel CSS changes meeting in one component. 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 “When a recorded resolution matches, rerere can update the conflicted file in the working tree while leaving review and staging to the user.” Apply this procedure: Read the reuse message, diff the file and stage only after semantic review. The expected mechanism is: The working tree may already contain the prior resolution, but the user still checks whether it fits the current context. For the website project, add one near-miss that exposes assuming a reused file is automatically accepted and committed. 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: science notes. Contrast the rule using a recurring conflict in a shared results table. 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 “When a recorded resolution matches, rerere can update the conflicted file in the working tree while leaving review and staging to the user.” Apply this procedure: Read the reuse message, diff the file and stage only after semantic review. The expected mechanism is: The working tree may already contain the prior resolution, but the user still checks whether it fits the current context. For the science notes, add one near-miss that exposes assuming a reused file is automatically accepted and committed. 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 reused file is automatically accepted and committed.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Read the reuse message, diff the file and stage only after semantic review.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Reuse edits the working tree by default?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming a reused file is automatically accepted and committed be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny documentation release with a long-lived fix merged into several release branches. Include one ordinary case, one boundary and one deliberate failure caused by assuming a reused file is automatically accepted and committed. 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: When a recorded resolution matches, rerere can update the conflicted file in the working tree while leaving review and staging to the user. It shows a trace, not only a final value. The ordinary case should demonstrate “The working tree may already contain the prior resolution, but the user still checks whether it fits the current context.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Read the reuse message, diff the file and stage only after semantic review. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Reuse edits the working tree by default, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
With rerere.autoupdate enabled or the command option requested, Git can update the index after applying a recorded resolution. 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 autoupdate before learning to inspect reused content. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Practise without autoupdate first and keep a staged-diff review gate when enabling it.
For the rerere.autoupdate can stage reused results chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on enabling autoupdate before learning to inspect reused content. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git config rerere.autoupdate true
git diff --cachedExplained result. A reused resolution can become staged automatically, so the cached diff is mandatory evidence before continuation. 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: website project. Transfer the rule using parallel CSS changes meeting in one component. 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 “With rerere.autoupdate enabled or the command option requested, Git can update the index after applying a recorded resolution.” Apply this procedure: Practise without autoupdate first and keep a staged-diff review gate when enabling it. The expected mechanism is: A reused resolution can become staged automatically, so the cached diff is mandatory evidence before continuation. For the website project, add one near-miss that exposes enabling autoupdate before learning to inspect reused content. 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: science notes. Predict the rule using a recurring conflict in a shared results table. 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 “With rerere.autoupdate enabled or the command option requested, Git can update the index after applying a recorded resolution.” Apply this procedure: Practise without autoupdate first and keep a staged-diff review gate when enabling it. The expected mechanism is: A reused resolution can become staged automatically, so the cached diff is mandatory evidence before continuation. For the science notes, add one near-miss that exposes enabling autoupdate before learning to inspect reused content. 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 repository. Contrast the rule using topic lists reordered on two branches. 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 “With rerere.autoupdate enabled or the command option requested, Git can update the index after applying a recorded resolution.” Apply this procedure: Practise without autoupdate first and keep a staged-diff review gate when enabling it. The expected mechanism is: A reused resolution can become staged automatically, so the cached diff is mandatory evidence before continuation. For the revision repository, add one near-miss that exposes enabling autoupdate before learning to inspect reused content. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Stress-test the rule using a long-lived fix merged into several release branches. 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 “With rerere.autoupdate enabled or the command option requested, Git can update the index after applying a recorded resolution.” Apply this procedure: Practise without autoupdate first and keep a staged-diff review gate when enabling it. The expected mechanism is: A reused resolution can become staged automatically, so the cached diff is mandatory evidence before continuation. For the documentation release, add one near-miss that exposes enabling autoupdate before learning to inspect reused content. 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 autoupdate before learning to inspect reused content.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Practise without autoupdate first and keep a staged-diff review gate when enabling it.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from rerere.autoupdate can stage reused results?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing enabling autoupdate before learning to inspect reused content be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny worktree lab with two linked worktrees rehearsing the same integration. Include one ordinary case, one boundary and one deliberate failure caused by enabling autoupdate before learning to inspect reused content. 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: With rerere.autoupdate enabled or the command option requested, Git can update the index after applying a recorded resolution. It shows a trace, not only a final value. The ordinary case should demonstrate “A reused resolution can become staged automatically, so the cached diff is mandatory evidence before continuation.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Practise without autoupdate first and keep a staged-diff review gate when enabling it. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For rerere.autoupdate can stage reused results, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 11 OF 20 . Handle boundaries
11. no-rerere-autoupdate preserves a review pause
The no-autoupdate option can stop automatic index updates for a particular invocation while still allowing reuse in the working 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 disabling all of rerere when only staging automation is the concern. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Separate reuse from acceptance and choose the narrower control.
For the no-rerere-autoupdate preserves a review pause chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on disabling all of rerere when only staging automation is the concern. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rerere --no-rerere-autoupdateExplained result. Recorded resolutions may be applied without immediately advancing them into the index. 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 repository. Predict the rule using topic lists reordered on two branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The no-autoupdate option can stop automatic index updates for a particular invocation while still allowing reuse in the working tree.” Apply this procedure: Separate reuse from acceptance and choose the narrower control. The expected mechanism is: Recorded resolutions may be applied without immediately advancing them into the index. For the revision repository, add one near-miss that exposes disabling all of rerere when only staging automation is the concern. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Contrast the rule using a long-lived fix merged into several release branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The no-autoupdate option can stop automatic index updates for a particular invocation while still allowing reuse in the working tree.” Apply this procedure: Separate reuse from acceptance and choose the narrower control. The expected mechanism is: Recorded resolutions may be applied without immediately advancing them into the index. For the documentation release, add one near-miss that exposes disabling all of rerere when only staging automation is the concern. 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: worktree lab. Stress-test the rule using two linked worktrees rehearsing the same integration. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The no-autoupdate option can stop automatic index updates for a particular invocation while still allowing reuse in the working tree.” Apply this procedure: Separate reuse from acceptance and choose the narrower control. The expected mechanism is: Recorded resolutions may be applied without immediately advancing them into the index. For the worktree lab, add one near-miss that exposes disabling all of rerere when only staging automation is the concern. 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: debug repository. Explain the rule using a disposable three-commit history with one reproducible conflict. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The no-autoupdate option can stop automatic index updates for a particular invocation while still allowing reuse in the working tree.” Apply this procedure: Separate reuse from acceptance and choose the narrower control. The expected mechanism is: Recorded resolutions may be applied without immediately advancing them into the index. For the debug repository, add one near-miss that exposes disabling all of rerere when only staging automation is the concern. 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 disabling all of rerere when only staging automation is the concern.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Separate reuse from acceptance and choose the narrower control.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final Git rerere syntax. For this chapter, useful prompts are: “What did you expect from no-rerere-autoupdate preserves a review pause?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing disabling all of rerere when only staging automation is the concern be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny debug repository with a disposable three-commit history with one reproducible conflict. Include one ordinary case, one boundary and one deliberate failure caused by disabling all of rerere when only staging automation is the concern. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The no-autoupdate option can stop automatic index updates for a particular invocation while still allowing reuse in the working tree. It shows a trace, not only a final value. The ordinary case should demonstrate “Recorded resolutions may be applied without immediately advancing them into the index.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Separate reuse from acceptance and choose the narrower control. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For no-rerere-autoupdate preserves a review pause, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
git rerere forget takes pathspecs and resets the recorded resolution for the current conflict so it can be resolved and learned again. 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 the whole cache because one resolution is wrong. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Recreate or remain in the relevant conflict, forget the affected path and resolve it carefully.
For the forget removes one learned resolution chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on deleting the whole cache because one resolution is wrong. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rerere forget report.txtExplained result. The current conflict for report.txt no longer uses the old recorded postimage and can teach a replacement. 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: worktree lab. Contrast the rule using two linked worktrees rehearsing the same integration. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere forget takes pathspecs and resets the recorded resolution for the current conflict so it can be resolved and learned again.” Apply this procedure: Recreate or remain in the relevant conflict, forget the affected path and resolve it carefully. The expected mechanism is: The current conflict for report.txt no longer uses the old recorded postimage and can teach a replacement. For the worktree lab, add one near-miss that exposes deleting the whole cache because one resolution is wrong. 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: debug repository. Stress-test the rule using a disposable three-commit history with one reproducible conflict. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere forget takes pathspecs and resets the recorded resolution for the current conflict so it can be resolved and learned again.” Apply this procedure: Recreate or remain in the relevant conflict, forget the affected path and resolve it carefully. The expected mechanism is: The current conflict for report.txt no longer uses the old recorded postimage and can teach a replacement. For the debug repository, add one near-miss that exposes deleting the whole cache because one resolution is wrong. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Explain the rule using a feature branch repeatedly rebased over a changing main branch. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere forget takes pathspecs and resets the recorded resolution for the current conflict so it can be resolved and learned again.” Apply this procedure: Recreate or remain in the relevant conflict, forget the affected path and resolve it carefully. The expected mechanism is: The current conflict for report.txt no longer uses the old recorded postimage and can teach a replacement. For the coding project, add one near-miss that exposes deleting the whole cache because one resolution is wrong. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Transfer the rule using two classmates editing the same report paragraph. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere forget takes pathspecs and resets the recorded resolution for the current conflict so it can be resolved and learned again.” Apply this procedure: Recreate or remain in the relevant conflict, forget the affected path and resolve it carefully. The expected mechanism is: The current conflict for report.txt no longer uses the old recorded postimage and can teach a replacement. For the group assignment, add one near-miss that exposes deleting the whole cache because one resolution is wrong. 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 the whole cache because one resolution is wrong.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Recreate or remain in the relevant conflict, forget the affected path and resolve it carefully.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from forget removes one learned resolution?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing deleting the whole cache because one resolution is wrong be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny coding project with a feature branch repeatedly rebased over a changing main branch. Include one ordinary case, one boundary and one deliberate failure caused by deleting the whole cache because one resolution is wrong. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: git rerere forget takes pathspecs and resets the recorded resolution for the current conflict so it can be resolved and learned again. It shows a trace, not only a final value. The ordinary case should demonstrate “The current conflict for report.txt no longer uses the old recorded postimage and can teach a replacement.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Recreate or remain in the relevant conflict, forget the affected path and resolve it carefully. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For forget removes one learned resolution, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
git rerere clear removes records for conflicts that have not completed, while preserving learned resolutions according to the documented lifecycle. 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 clear as if it were a full cache purge. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect rr-cache before and after in a disposable repository and name which records are unresolved.
For the clear removes unresolved records chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using clear as if it were a full cache purge. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rerere clearExplained result. Unresolved conflict records are cleared; this command is not the same as deleting every successful historical resolution. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Stress-test the rule using a feature branch repeatedly rebased over a changing main branch. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere clear removes records for conflicts that have not completed, while preserving learned resolutions according to the documented lifecycle.” Apply this procedure: Inspect rr-cache before and after in a disposable repository and name which records are unresolved. The expected mechanism is: Unresolved conflict records are cleared; this command is not the same as deleting every successful historical resolution. For the coding project, add one near-miss that exposes using clear as if it were a full cache purge. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Explain the rule using two classmates editing the same report paragraph. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere clear removes records for conflicts that have not completed, while preserving learned resolutions according to the documented lifecycle.” Apply this procedure: Inspect rr-cache before and after in a disposable repository and name which records are unresolved. The expected mechanism is: Unresolved conflict records are cleared; this command is not the same as deleting every successful historical resolution. For the group assignment, add one near-miss that exposes using clear as if it were a full cache purge. 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: website project. Transfer the rule using parallel CSS changes meeting in one component. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere clear removes records for conflicts that have not completed, while preserving learned resolutions according to the documented lifecycle.” Apply this procedure: Inspect rr-cache before and after in a disposable repository and name which records are unresolved. The expected mechanism is: Unresolved conflict records are cleared; this command is not the same as deleting every successful historical resolution. For the website project, add one near-miss that exposes using clear as if it were a full cache purge. 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: science notes. Predict the rule using a recurring conflict in a shared results table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere clear removes records for conflicts that have not completed, while preserving learned resolutions according to the documented lifecycle.” Apply this procedure: Inspect rr-cache before and after in a disposable repository and name which records are unresolved. The expected mechanism is: Unresolved conflict records are cleared; this command is not the same as deleting every successful historical resolution. For the science notes, add one near-miss that exposes using clear as if it were a full cache purge. 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 clear as if it were a full cache purge.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect rr-cache before and after in a disposable repository and name which records are unresolved.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from clear removes unresolved records?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using clear as if it were a full cache purge be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny group assignment with two classmates editing the same report paragraph. Include one ordinary case, one boundary and one deliberate failure caused by using clear as if it were a full cache purge. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: git rerere clear removes records for conflicts that have not completed, while preserving learned resolutions according to the documented lifecycle. It shows a trace, not only a final value. The ordinary case should demonstrate “Unresolved conflict records are cleared; this command is not the same as deleting every successful historical resolution.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect rr-cache before and after in a disposable repository and name which records are unresolved. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For clear removes unresolved records, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
git rerere gc prunes old resolution records using configured age thresholds that differ for resolved and unresolved entries. 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 immediate LRU-style size eviction. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Read gc.rerereResolved and gc.rerereUnresolved policy, date test fixtures carefully and avoid manual cache guesses.
For the gc expires old records chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting immediate LRU-style size eviction. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rerere gcExplained result. Old records past the configured cutoffs are removed during garbage collection. 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: website project. Explain the rule using parallel CSS changes meeting in one component. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere gc prunes old resolution records using configured age thresholds that differ for resolved and unresolved entries.” Apply this procedure: Read gc.rerereResolved and gc.rerereUnresolved policy, date test fixtures carefully and avoid manual cache guesses. The expected mechanism is: Old records past the configured cutoffs are removed during garbage collection. For the website project, add one near-miss that exposes expecting immediate LRU-style size eviction. 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: science notes. Transfer the rule using a recurring conflict in a shared results table. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere gc prunes old resolution records using configured age thresholds that differ for resolved and unresolved entries.” Apply this procedure: Read gc.rerereResolved and gc.rerereUnresolved policy, date test fixtures carefully and avoid manual cache guesses. The expected mechanism is: Old records past the configured cutoffs are removed during garbage collection. For the science notes, add one near-miss that exposes expecting immediate LRU-style size eviction. 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 repository. Predict the rule using topic lists reordered on two branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere gc prunes old resolution records using configured age thresholds that differ for resolved and unresolved entries.” Apply this procedure: Read gc.rerereResolved and gc.rerereUnresolved policy, date test fixtures carefully and avoid manual cache guesses. The expected mechanism is: Old records past the configured cutoffs are removed during garbage collection. For the revision repository, add one near-miss that exposes expecting immediate LRU-style size eviction. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Contrast the rule using a long-lived fix merged into several release branches. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “git rerere gc prunes old resolution records using configured age thresholds that differ for resolved and unresolved entries.” Apply this procedure: Read gc.rerereResolved and gc.rerereUnresolved policy, date test fixtures carefully and avoid manual cache guesses. The expected mechanism is: Old records past the configured cutoffs are removed during garbage collection. For the documentation release, add one near-miss that exposes expecting immediate LRU-style size eviction. 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 immediate LRU-style size eviction.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Read gc.rerereResolved and gc.rerereUnresolved policy, date test fixtures carefully and avoid manual cache guesses.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from gc expires old records?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting immediate LRU-style size eviction be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny website project with parallel CSS changes meeting in one component. Include one ordinary case, one boundary and one deliberate failure caused by expecting immediate LRU-style size eviction. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: git rerere gc prunes old resolution records using configured age thresholds that differ for resolved and unresolved entries. It shows a trace, not only a final value. The ordinary case should demonstrate “Old records past the configured cutoffs are removed during garbage collection.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Read gc.rerereResolved and gc.rerereUnresolved policy, date test fixtures carefully and avoid manual cache guesses. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For gc expires old records, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Any workflow that recreates a sufficiently similar textual conflict can benefit, including repeated merges, rebases and cherry-picks. 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 teaching rerere as a merge-only feature. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Rehearse the same conflict through two history operations and compare preimages and reuse.
For the Merges, rebases and cherry-picks can benefit chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on teaching rerere as a merge-only feature. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rebase main
# resolve and continue; later repeat on updated historyExplained result. A recurring conflict during rebase can reuse the prior resolution when its canonical conflict shape matches. 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 repository. Transfer the rule using topic lists reordered on two branches. 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 “Any workflow that recreates a sufficiently similar textual conflict can benefit, including repeated merges, rebases and cherry-picks.” Apply this procedure: Rehearse the same conflict through two history operations and compare preimages and reuse. The expected mechanism is: A recurring conflict during rebase can reuse the prior resolution when its canonical conflict shape matches. For the revision repository, add one near-miss that exposes teaching rerere as a merge-only feature. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Predict the rule using a long-lived fix merged into several release branches. 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 “Any workflow that recreates a sufficiently similar textual conflict can benefit, including repeated merges, rebases and cherry-picks.” Apply this procedure: Rehearse the same conflict through two history operations and compare preimages and reuse. The expected mechanism is: A recurring conflict during rebase can reuse the prior resolution when its canonical conflict shape matches. For the documentation release, add one near-miss that exposes teaching rerere as a merge-only feature. 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: worktree lab. Contrast the rule using two linked worktrees rehearsing the same integration. 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 “Any workflow that recreates a sufficiently similar textual conflict can benefit, including repeated merges, rebases and cherry-picks.” Apply this procedure: Rehearse the same conflict through two history operations and compare preimages and reuse. The expected mechanism is: A recurring conflict during rebase can reuse the prior resolution when its canonical conflict shape matches. For the worktree lab, add one near-miss that exposes teaching rerere as a merge-only feature. 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: debug repository. Stress-test the rule using a disposable three-commit history with one reproducible conflict. 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 “Any workflow that recreates a sufficiently similar textual conflict can benefit, including repeated merges, rebases and cherry-picks.” Apply this procedure: Rehearse the same conflict through two history operations and compare preimages and reuse. The expected mechanism is: A recurring conflict during rebase can reuse the prior resolution when its canonical conflict shape matches. For the debug repository, add one near-miss that exposes teaching rerere as a merge-only feature. 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 teaching rerere as a merge-only feature.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Rehearse the same conflict through two history operations and compare preimages and reuse.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Merges, rebases and cherry-picks can benefit?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing teaching rerere as a merge-only feature be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science notes with a recurring conflict in a shared results table. Include one ordinary case, one boundary and one deliberate failure caused by teaching rerere as a merge-only feature. 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: Any workflow that recreates a sufficiently similar textual conflict can benefit, including repeated merges, rebases and cherry-picks. It shows a trace, not only a final value. The ordinary case should demonstrate “A recurring conflict during rebase can reuse the prior resolution when its canonical conflict shape matches.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Rehearse the same conflict through two history operations and compare preimages and reuse. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Merges, rebases and cherry-picks can benefit, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
rerere recognises conflict shapes through canonicalisation, but materially changed surrounding edits can produce a different conflict or make an old resolution semantically wrong. 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 reuse whenever the same file conflicts. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal.
For the Conflict normalisation has boundaries chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on promising reuse whenever the same file conflicts. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git rerere diffExplained result. The diff helps determine whether the remembered transformation still corresponds to the current conflict. 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: worktree lab. Predict the rule using two linked worktrees rehearsing the same integration. 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 “rerere recognises conflict shapes through canonicalisation, but materially changed surrounding edits can produce a different conflict or make an old resolution semantically wrong.” Apply this procedure: Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal. The expected mechanism is: The diff helps determine whether the remembered transformation still corresponds to the current conflict. For the worktree lab, add one near-miss that exposes promising reuse whenever the same file conflicts. 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: debug repository. Contrast the rule using a disposable three-commit history with one reproducible conflict. 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 “rerere recognises conflict shapes through canonicalisation, but materially changed surrounding edits can produce a different conflict or make an old resolution semantically wrong.” Apply this procedure: Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal. The expected mechanism is: The diff helps determine whether the remembered transformation still corresponds to the current conflict. For the debug repository, add one near-miss that exposes promising reuse whenever the same file conflicts. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Stress-test the rule using a feature branch repeatedly rebased over a changing main branch. 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 “rerere recognises conflict shapes through canonicalisation, but materially changed surrounding edits can produce a different conflict or make an old resolution semantically wrong.” Apply this procedure: Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal. The expected mechanism is: The diff helps determine whether the remembered transformation still corresponds to the current conflict. For the coding project, add one near-miss that exposes promising reuse whenever the same file conflicts. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Explain the rule using two classmates editing the same report paragraph. 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 “rerere recognises conflict shapes through canonicalisation, but materially changed surrounding edits can produce a different conflict or make an old resolution semantically wrong.” Apply this procedure: Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal. The expected mechanism is: The diff helps determine whether the remembered transformation still corresponds to the current conflict. For the group assignment, add one near-miss that exposes promising reuse whenever the same file conflicts. 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 reuse whenever the same file conflicts.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Conflict normalisation has boundaries?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing promising reuse whenever the same file conflicts be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision repository with topic lists reordered on two branches. Include one ordinary case, one boundary and one deliberate failure caused by promising reuse whenever the same file conflicts. 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: rerere recognises conflict shapes through canonicalisation, but materially changed surrounding edits can produce a different conflict or make an old resolution semantically wrong. It shows a trace, not only a final value. The ordinary case should demonstrate “The diff helps determine whether the remembered transformation still corresponds to the current conflict.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Conflict normalisation has boundaries, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A mechanically matching resolution may no longer express the intended program behaviour, documentation meaning or data 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 accepting reused content because conflict markers disappeared. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Run tests, inspect context and ask whether both new branch changes remain represented.
For the Reused is not necessarily correct chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on accepting reused content because conflict markers disappeared. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git diff --cached
run_project_testsExplained result. Semantic validation follows textual reuse; a clean index cannot prove the result is correct. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: coding project. Contrast the rule using a feature branch repeatedly rebased over a changing main branch. 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 mechanically matching resolution may no longer express the intended program behaviour, documentation meaning or data policy.” Apply this procedure: Run tests, inspect context and ask whether both new branch changes remain represented. The expected mechanism is: Semantic validation follows textual reuse; a clean index cannot prove the result is correct. For the coding project, add one near-miss that exposes accepting reused content because conflict markers disappeared. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: group assignment. Stress-test the rule using two classmates editing the same report paragraph. 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 mechanically matching resolution may no longer express the intended program behaviour, documentation meaning or data policy.” Apply this procedure: Run tests, inspect context and ask whether both new branch changes remain represented. The expected mechanism is: Semantic validation follows textual reuse; a clean index cannot prove the result is correct. For the group assignment, add one near-miss that exposes accepting reused content because conflict markers disappeared. 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: website project. Explain the rule using parallel CSS changes meeting in one component. 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 mechanically matching resolution may no longer express the intended program behaviour, documentation meaning or data policy.” Apply this procedure: Run tests, inspect context and ask whether both new branch changes remain represented. The expected mechanism is: Semantic validation follows textual reuse; a clean index cannot prove the result is correct. For the website project, add one near-miss that exposes accepting reused content because conflict markers disappeared. 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: science notes. Transfer the rule using a recurring conflict in a shared results table. 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 mechanically matching resolution may no longer express the intended program behaviour, documentation meaning or data policy.” Apply this procedure: Run tests, inspect context and ask whether both new branch changes remain represented. The expected mechanism is: Semantic validation follows textual reuse; a clean index cannot prove the result is correct. For the science notes, add one near-miss that exposes accepting reused content because conflict markers disappeared. 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 accepting reused content because conflict markers disappeared.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Run tests, inspect context and ask whether both new branch changes remain represented.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Reused is not necessarily correct?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing accepting reused content because conflict markers disappeared be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny documentation release with a long-lived fix merged into several release branches. Include one ordinary case, one boundary and one deliberate failure caused by accepting reused content because conflict markers disappeared. 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 mechanically matching resolution may no longer express the intended program behaviour, documentation meaning or data policy. It shows a trace, not only a final value. The ordinary case should demonstrate “Semantic validation follows textual reuse; a clean index cannot prove the result is correct.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Run tests, inspect context and ask whether both new branch changes remain represented. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Reused is not necessarily correct, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 18 OF 20 . Transfer with judgment
18. Sharing rr-cache is an explicit trust choice
Teams can copy or otherwise share recorded resolution data, but the cache carries executable-project decisions that require provenance and compatibility judgment. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is syncing .git/rr-cache casually as if it were ordinary source files. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Define who produced the resolution, which project state it covers and how recipients review reuse.
For the Sharing rr-cache is an explicit trust choice chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on syncing .git/rr-cache casually as if it were ordinary source files. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
tar -C .git -cf rerere-cache.tar rr-cacheExplained result. An archive can transport records, but sharing is a project policy rather than a default Git collaboration channel. 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: website project. Stress-test the rule using parallel CSS changes meeting in one component. 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 “Teams can copy or otherwise share recorded resolution data, but the cache carries executable-project decisions that require provenance and compatibility judgment.” Apply this procedure: Define who produced the resolution, which project state it covers and how recipients review reuse. The expected mechanism is: An archive can transport records, but sharing is a project policy rather than a default Git collaboration channel. For the website project, add one near-miss that exposes syncing .git/rr-cache casually as if it were ordinary source files. 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: science notes. Explain the rule using a recurring conflict in a shared results table. 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 “Teams can copy or otherwise share recorded resolution data, but the cache carries executable-project decisions that require provenance and compatibility judgment.” Apply this procedure: Define who produced the resolution, which project state it covers and how recipients review reuse. The expected mechanism is: An archive can transport records, but sharing is a project policy rather than a default Git collaboration channel. For the science notes, add one near-miss that exposes syncing .git/rr-cache casually as if it were ordinary source files. 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 repository. Transfer the rule using topic lists reordered on two branches. 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 “Teams can copy or otherwise share recorded resolution data, but the cache carries executable-project decisions that require provenance and compatibility judgment.” Apply this procedure: Define who produced the resolution, which project state it covers and how recipients review reuse. The expected mechanism is: An archive can transport records, but sharing is a project policy rather than a default Git collaboration channel. For the revision repository, add one near-miss that exposes syncing .git/rr-cache casually as if it were ordinary source files. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: documentation release. Predict the rule using a long-lived fix merged into several release branches. 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 “Teams can copy or otherwise share recorded resolution data, but the cache carries executable-project decisions that require provenance and compatibility judgment.” Apply this procedure: Define who produced the resolution, which project state it covers and how recipients review reuse. The expected mechanism is: An archive can transport records, but sharing is a project policy rather than a default Git collaboration channel. For the documentation release, add one near-miss that exposes syncing .git/rr-cache casually as if it were ordinary source files. 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 syncing .git/rr-cache casually as if it were ordinary source files.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Define who produced the resolution, which project state it covers and how recipients review reuse.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Sharing rr-cache is an explicit trust choice?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing syncing .git/rr-cache casually as if it were ordinary source files be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny worktree lab with two linked worktrees rehearsing the same integration. Include one ordinary case, one boundary and one deliberate failure caused by syncing .git/rr-cache casually as if it were ordinary source files. 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: Teams can copy or otherwise share recorded resolution data, but the cache carries executable-project decisions that require provenance and compatibility judgment. It shows a trace, not only a final value. The ordinary case should demonstrate “An archive can transport records, but sharing is a project policy rather than a default Git collaboration channel.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Define who produced the resolution, which project state it covers and how recipients review reuse. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Sharing rr-cache is an explicit trust choice, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Linked worktrees share repository administration data in ways that can make rerere records available across their integrations, while each worktree has its own checked-out state. 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 resolving in one terminal and assuming another worktree is at the same history-operation step. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Label every path and run status inside each worktree before acting.
For the Worktrees and repository-local state chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on resolving in one terminal and assuming another worktree is at the same history-operation step. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git -C ../integration-tree status --short
git -C ../integration-tree rerere statusExplained result. The commands inspect one named worktree while the repository-level cache can still provide learned resolutions. 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 repository. Explain the rule using topic lists reordered on two branches. 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 “Linked worktrees share repository administration data in ways that can make rerere records available across their integrations, while each worktree has its own checked-out state.” Apply this procedure: Label every path and run status inside each worktree before acting. The expected mechanism is: The commands inspect one named worktree while the repository-level cache can still provide learned resolutions. For the revision repository, add one near-miss that exposes resolving in one terminal and assuming another worktree is at the same history-operation step. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: documentation release. Transfer the rule using a long-lived fix merged into several release branches. 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 “Linked worktrees share repository administration data in ways that can make rerere records available across their integrations, while each worktree has its own checked-out state.” Apply this procedure: Label every path and run status inside each worktree before acting. The expected mechanism is: The commands inspect one named worktree while the repository-level cache can still provide learned resolutions. For the documentation release, add one near-miss that exposes resolving in one terminal and assuming another worktree is at the same history-operation step. 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: worktree lab. Predict the rule using two linked worktrees rehearsing the same integration. 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 “Linked worktrees share repository administration data in ways that can make rerere records available across their integrations, while each worktree has its own checked-out state.” Apply this procedure: Label every path and run status inside each worktree before acting. The expected mechanism is: The commands inspect one named worktree while the repository-level cache can still provide learned resolutions. For the worktree lab, add one near-miss that exposes resolving in one terminal and assuming another worktree is at the same history-operation step. 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: debug repository. Contrast the rule using a disposable three-commit history with one reproducible conflict. 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 “Linked worktrees share repository administration data in ways that can make rerere records available across their integrations, while each worktree has its own checked-out state.” Apply this procedure: Label every path and run status inside each worktree before acting. The expected mechanism is: The commands inspect one named worktree while the repository-level cache can still provide learned resolutions. For the debug repository, add one near-miss that exposes resolving in one terminal and assuming another worktree is at the same history-operation step. 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 resolving in one terminal and assuming another worktree is at the same history-operation step.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Label every path and run status inside each worktree before acting.” 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from Worktrees and repository-local state?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing resolving in one terminal and assuming another worktree is at the same history-operation step be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny debug repository with a disposable three-commit history with one reproducible conflict. Include one ordinary case, one boundary and one deliberate failure caused by resolving in one terminal and assuming another worktree is at the same history-operation step. 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: Linked worktrees share repository administration data in ways that can make rerere records available across their integrations, while each worktree has its own checked-out state. It shows a trace, not only a final value. The ordinary case should demonstrate “The commands inspect one named worktree while the repository-level cache can still provide learned resolutions.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Label every path and run status inside each worktree before acting. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Worktrees and repository-local state, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Mastery comes from creating a minimal conflict, recording one resolution, aborting or resetting safely, recreating the conflict and verifying reuse with diffs and tests. 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 first experimenting inside an important school or production repository. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use a temporary repository, tag clean checkpoints and write the expected state before every merge, reset or continue command.
For the A disposable conflict laboratory chapter on Git rerere, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on first experimenting inside an important school or production repository. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
git init rerere-lab
cd rerere-lab
git config rerere.enabled trueExplained result. The laboratory isolates stateful practice so the learner can inspect rr-cache, make mistakes and start again without risking valued work. 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: worktree lab. Transfer the rule using two linked worktrees rehearsing the same integration. 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 comes from creating a minimal conflict, recording one resolution, aborting or resetting safely, recreating the conflict and verifying reuse with diffs and tests.” Apply this procedure: Use a temporary repository, tag clean checkpoints and write the expected state before every merge, reset or continue command. The expected mechanism is: The laboratory isolates stateful practice so the learner can inspect rr-cache, make mistakes and start again without risking valued work. For the worktree lab, add one near-miss that exposes first experimenting inside an important school or production repository. 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: debug repository. Predict the rule using a disposable three-commit history with one reproducible conflict. 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 comes from creating a minimal conflict, recording one resolution, aborting or resetting safely, recreating the conflict and verifying reuse with diffs and tests.” Apply this procedure: Use a temporary repository, tag clean checkpoints and write the expected state before every merge, reset or continue command. The expected mechanism is: The laboratory isolates stateful practice so the learner can inspect rr-cache, make mistakes and start again without risking valued work. For the debug repository, add one near-miss that exposes first experimenting inside an important school or production repository. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: coding project. Contrast the rule using a feature branch repeatedly rebased over a changing main branch. 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 comes from creating a minimal conflict, recording one resolution, aborting or resetting safely, recreating the conflict and verifying reuse with diffs and tests.” Apply this procedure: Use a temporary repository, tag clean checkpoints and write the expected state before every merge, reset or continue command. The expected mechanism is: The laboratory isolates stateful practice so the learner can inspect rr-cache, make mistakes and start again without risking valued work. For the coding project, add one near-miss that exposes first experimenting inside an important school or production repository. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: group assignment. Stress-test the rule using two classmates editing the same report paragraph. 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 comes from creating a minimal conflict, recording one resolution, aborting or resetting safely, recreating the conflict and verifying reuse with diffs and tests.” Apply this procedure: Use a temporary repository, tag clean checkpoints and write the expected state before every merge, reset or continue command. The expected mechanism is: The laboratory isolates stateful practice so the learner can inspect rr-cache, make mistakes and start again without risking valued work. For the group assignment, add one near-miss that exposes first experimenting inside an important school or production repository. 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 first experimenting inside an important school or production repository.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use a temporary repository, tag clean checkpoints and write the expected state before every merge, reset or continue 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 Git rerere syntax. For this chapter, useful prompts are: “What did you expect from A disposable conflict laboratory?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing first experimenting inside an important school or production repository be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny coding project with a feature branch repeatedly rebased over a changing main branch. Include one ordinary case, one boundary and one deliberate failure caused by first experimenting inside an important school or production repository. 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 comes from creating a minimal conflict, recording one resolution, aborting or resetting safely, recreating the conflict and verifying reuse with diffs and tests. It shows a trace, not only a final value. The ordinary case should demonstrate “The laboratory isolates stateful practice so the learner can inspect rr-cache, make mistakes and start again without risking valued work.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use a temporary repository, tag clean checkpoints and write the expected state before every merge, reset or continue command. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A disposable conflict laboratory, separate the documented Git rerere mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Parent guide: choose the next useful step
Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.
Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.
Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.
Capstone practice with explained routes
1. coding project: model, boundary and recovery
Create a small coding project using a feature branch repeatedly rebased over a changing main branch. Combine “Reuse recorded resolution” 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: rerere observes conflicted file preimages, records the human resolution and can reuse it when an equivalent conflict appears later. Apply: Create the conflict once, resolve it deliberately, recreate it and compare the reused working-tree result. Verify: Git records the conflict shape; after the file is resolved and staged, it can learn the resolution for a future match. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
2. group assignment: model, boundary and recovery
Create a small group assignment using two classmates editing the same report paragraph. Combine “Postimages capture the resolved content” 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: After the user resolves and stages the conflicted path, rerere records the resolved file as a postimage associated with the preimage. Apply: Resolve markers, review the file and use git add so Git can observe completion. Verify: Staging marks the conflict resolved, allowing the resolved content to be recorded for reuse. 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. website project: model, boundary and recovery
Create a small website project using parallel CSS changes meeting in one component. Combine “git rerere diff shows resolution progress” 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: rerere diff displays differences between the conflict preimage and the current working resolution, helping review what was changed. Apply: Inspect rerere diff, ordinary diff and staged diff before continuing the history operation. Verify: The first focuses on recorded conflict resolution progress; the second catches whitespace errors in unstaged changes. 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. science notes: model, boundary and recovery
Create a small science notes using a recurring conflict in a shared results table. Combine “rerere.autoupdate can stage reused results” 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: With rerere.autoupdate enabled or the command option requested, Git can update the index after applying a recorded resolution. Apply: Practise without autoupdate first and keep a staged-diff review gate when enabling it. Verify: A reused resolution can become staged automatically, so the cached diff is mandatory evidence before continuation. 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 repository: model, boundary and recovery
Create a small revision repository using topic lists reordered on two branches. Combine “clear removes unresolved records” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: git rerere clear removes records for conflicts that have not completed, while preserving learned resolutions according to the documented lifecycle. Apply: Inspect rr-cache before and after in a disposable repository and name which records are unresolved. Verify: Unresolved conflict records are cleared; this command is not the same as deleting every successful historical resolution. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
6. documentation release: model, boundary and recovery
Create a small documentation release using a long-lived fix merged into several release branches. Combine “Conflict normalisation has boundaries” 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: rerere recognises conflict shapes through canonicalisation, but materially changed surrounding edits can produce a different conflict or make an old resolution semantically wrong. Apply: Compare the actual preimage and business meaning; treat a non-match or suspicious reuse as a review signal. Verify: The diff helps determine whether the remembered transformation still corresponds to the current conflict. 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. worktree lab: model, boundary and recovery
Create a small worktree lab using two linked worktrees rehearsing the same integration. Combine “Worktrees and repository-local state” 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: Linked worktrees share repository administration data in ways that can make rerere records available across their integrations, while each worktree has its own checked-out state. Apply: Label every path and run status inside each worktree before acting. Verify: The commands inspect one named worktree while the repository-level cache can still provide learned resolutions. 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. debug repository: model, boundary and recovery
Create a small debug repository using a disposable three-commit history with one reproducible conflict. Combine “Enable locally or globally with intent” 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: rerere.enabled can be set in one repository or globally, and an rr-cache directory can also make the facility active in documented configurations. Apply: Begin in a disposable repository with local config, then decide whether global reuse matches the user workflow. Verify: The repository now records and reuses eligible resolutions without changing unrelated repositories. 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.
