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 subtree places another project inside a subdirectory of a main repository and can move history between the combined repository and the subproject. Ordinary clones see normal tracked files, but maintainers need a deliberate prefix, remote, split and squash policy. Mastery means rehearsing add, pull, push and split in disposable repositories, understanding the commit trailers used to reconnect history, and protecting both projects before synchronization. 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.

After addition, subtree files live under a normal directory in the main repository and ordinary clones do not need special checkout steps. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is calling the directory a linked checkout like a submodule. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Clone the main repository elsewhere and inspect files and configuration.

For the A subtree is ordinary tracked content chapter on Git subtree, 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 calling the directory a linked checkout like a submodule. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git clone main.git learner-copy

Four purposeful transfer cases

Case 1: coding assignment. Predict the rule using a shared utility folder used by two projects. 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.

Case 2: group website. Contrast the rule using a theme maintained in its own repository. 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.

Case 3: CCA app. Stress-test the rule using a reusable registration 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.

Case 4: science scripts. Explain the rule using a plotting library embedded under vendor. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers calling the directory a linked checkout like a submodule.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Clone the main repository elsewhere and inspect files and configuration.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from A subtree is ordinary tracked content?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling the directory a linked checkout like a submodule be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family project with a small library contributed back upstream. Include one ordinary case, one boundary and one deliberate failure caused by calling the directory a linked checkout like a submodule. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A subtree is ordinary tracked content, separate the documented Git subtree 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

–prefix names the subdirectory that belongs to the subtree workflow and should be kept distinct from unrelated main-project edits. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is choosing a prefix that already contains mixed local files. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use a dedicated path and document its upstream source.

For the The prefix defines the ownership boundary chapter on Git subtree, 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 choosing a prefix that already contains mixed local files. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree add --prefix=vendor/quiz quiz main

Four purposeful transfer cases

Case 1: CCA app. Contrast the rule using a reusable registration 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.

Case 2: science scripts. Stress-test the rule using a plotting library embedded under vendor. 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.

Case 3: revision repository. Explain the rule using shared quiz data kept under packages. 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.

Case 4: family project. Transfer the rule using a small library contributed back upstream. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers choosing a prefix that already contains mixed local files.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use a dedicated path and document its upstream source.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from The prefix defines the ownership boundary?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing choosing a prefix that already contains mixed local files be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny release exercise with squashed and unsquashed update histories. Include one ordinary case, one boundary and one deliberate failure caused by choosing a prefix that already contains mixed local files. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The prefix defines the ownership boundary, separate the documented Git subtree 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 subtree is distributed in the Git source tree under contrib and availability can depend on how Git was packaged. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming every machine has the command because git itself exists. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Run git subtree -h in the target environment before designing the workflow.

For the The command lives in Git contrib chapter on Git subtree, 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 every machine has the command because git itself exists. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree -h

Four purposeful transfer cases

Case 1: revision repository. Stress-test the rule using shared quiz data kept under packages. 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.

Case 2: family project. Explain the rule using a small library contributed back upstream. 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.

Case 3: release exercise. Transfer the rule using squashed and unsquashed update histories. 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.

Case 4: disposable Git laboratory. Predict the rule using local remotes, controlled prefixes and exact trees. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming every machine has the command because git itself exists.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Run git subtree -h in the target environment before designing the 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from The command lives in Git contrib?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming every machine has the command because git itself exists be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny disposable Git laboratory with local remotes, controlled prefixes and exact trees. Include one ordinary case, one boundary and one deliberate failure caused by assuming every machine has the command because git itself exists. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The command lives in Git contrib, separate the documented Git subtree 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 subtree add creates the initial import for a prefix from a repository and revision, with optional squashing. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is running add repeatedly when the prefix already belongs to a subtree. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use pull for later upstream updates.

For the Add imports a project once chapter on Git subtree, 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 running add repeatedly when the prefix already belongs to a subtree. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree add --prefix=lib/shared ../shared main

Four purposeful transfer cases

Case 1: release exercise. Explain the rule using squashed and unsquashed update histories. 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.

Case 2: disposable Git laboratory. Transfer the rule using local remotes, controlled prefixes and exact trees. 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.

Case 3: coding assignment. Predict the rule using a shared utility folder used by two projects. 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.

Case 4: group website. Contrast the rule using a theme maintained in its own repository. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers running add repeatedly when the prefix already belongs to a subtree.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use pull for later upstream updates.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Add imports a project once?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing running add repeatedly when the prefix already belongs to a subtree be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny coding assignment with a shared utility folder used by two projects. Include one ordinary case, one boundary and one deliberate failure caused by running add repeatedly when the prefix already belongs to a subtree. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Add imports a project once, separate the documented Git subtree 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

Repository arguments can be URLs or local paths, while a named remote makes repeated collaboration clearer. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding a remote and assuming fetch or push policy is automatic. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Name, fetch and inspect the remote deliberately.

For the A remote name is optional but useful chapter on Git subtree, 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 adding a remote and assuming fetch or push policy is automatic. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git remote add shared ../shared.git
git fetch shared

Four purposeful transfer cases

Case 1: coding assignment. Transfer the rule using a shared utility folder used by two projects. 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.

Case 2: group website. Predict the rule using a theme maintained in its own repository. 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.

Case 3: CCA app. Contrast the rule using a reusable registration 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.

Case 4: science scripts. Stress-test the rule using a plotting library embedded under vendor. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding a remote and assuming fetch or push policy is automatic.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Name, fetch and inspect the remote deliberately.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Git subtree syntax. For this chapter, useful prompts are: “What did you expect from A remote name is optional but useful?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding a remote and assuming fetch or push policy is automatic be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny group website with a theme maintained in its own repository. Include one ordinary case, one boundary and one deliberate failure caused by adding a remote and assuming fetch or push policy is automatic. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A remote name is optional but useful, separate the documented Git subtree 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

–squash imports each update as one synthetic commit rather than joining the complete subproject history into the main history. 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 switching casually between squashed and unsquashed workflows. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Choose the history policy at project start and rehearse updates.

For the Squash chooses a condensed import history chapter on Git subtree, 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 switching casually between squashed and unsquashed workflows. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree add --prefix=lib/shared shared main --squash

Four purposeful transfer cases

Case 1: CCA app. Predict the rule using a reusable registration 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.

Case 2: science scripts. Contrast the rule using a plotting library embedded under vendor. 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.

Case 3: revision repository. Stress-test the rule using shared quiz data kept under packages. 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.

Case 4: family project. Explain the rule using a small library contributed back upstream. 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.

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 switching casually between squashed and unsquashed workflows.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Choose the history policy at project start and rehearse updates.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Squash chooses a condensed import history?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing switching casually between squashed and unsquashed workflows be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA app with a reusable registration component. Include one ordinary case, one boundary and one deliberate failure caused by switching casually between squashed and unsquashed workflows. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Squash chooses a condensed import history, separate the documented Git subtree 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

Without –squash, subtree operations can join the subproject’s commit history into the main repository. 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 a simple log without examining the resulting merges and ancestry. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Visualise the graph after a disposable import.

For the Unsquashed mode preserves joined history chapter on Git subtree, 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 a simple log without examining the resulting merges and ancestry. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git log --graph --oneline --all

Four purposeful transfer cases

Case 1: revision repository. Contrast the rule using shared quiz data kept under packages. 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.

Case 2: family project. Stress-test the rule using a small library contributed back upstream. 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.

Case 3: release exercise. Explain the rule using squashed and unsquashed update histories. 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.

Case 4: disposable Git laboratory. Transfer the rule using local remotes, controlled prefixes and exact trees. 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.

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 a simple log without examining the resulting merges and ancestry.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Visualise the graph after a disposable import.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Unsquashed mode preserves joined history?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing promising a simple log without examining the resulting merges and ancestry be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science scripts with a plotting library embedded under vendor. Include one ordinary case, one boundary and one deliberate failure caused by promising a simple log without examining the resulting merges and ancestry. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Unsquashed mode preserves joined history, separate the documented Git subtree 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 subtree pull brings a later remote revision into the prefix using the chosen history 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 editing upstream files locally and expecting pull to resolve every conflict automatically. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Commit or preserve local work, fetch, inspect and pull in a clean state.

For the Pull fetches and merges upstream changes chapter on Git subtree, 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 upstream files locally and expecting pull to resolve every conflict automatically. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree pull --prefix=lib/shared shared main --squash

Four purposeful transfer cases

Case 1: release exercise. Stress-test the rule using squashed and unsquashed update histories. 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.

Case 2: disposable Git laboratory. Explain the rule using local remotes, controlled prefixes and exact trees. 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.

Case 3: coding assignment. Transfer the rule using a shared utility folder used by two projects. 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.

Case 4: group website. Predict the rule using a theme maintained in its own repository. 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.

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 upstream files locally and expecting pull to resolve every conflict automatically.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Commit or preserve local work, fetch, inspect and pull in a clean state.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final Git subtree syntax. For this chapter, useful prompts are: “What did you expect from Pull fetches and merges upstream changes?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing editing upstream files locally and expecting pull to resolve every conflict automatically 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 shared quiz data kept under packages. Include one ordinary case, one boundary and one deliberate failure caused by editing upstream files locally and expecting pull to resolve every conflict automatically. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Pull fetches and merges upstream changes, separate the documented Git subtree 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 subtree pull can conflict when both sides changed corresponding content, and recovery follows Git merge discipline. 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 prefix and re-adding it to escape a conflict. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect status, resolve exact files, test and continue or abort safely.

For the Conflicts are ordinary merge conflicts with a boundary chapter on Git subtree, 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 prefix and re-adding it to escape a conflict. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git status --short

Four purposeful transfer cases

Case 1: coding assignment. Explain the rule using a shared utility folder used by two projects. 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.

Case 2: group website. Transfer the rule using a theme maintained in its own repository. 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.

Case 3: CCA app. Predict the rule using a reusable registration 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.

Case 4: science scripts. Contrast the rule using a plotting library embedded under vendor. 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.

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 prefix and re-adding it to escape a conflict.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect status, resolve exact files, test and continue or abort safely.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Conflicts are ordinary merge conflicts with a boundary?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing deleting the prefix and re-adding it to escape a conflict be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family project with a small library contributed back upstream. Include one ordinary case, one boundary and one deliberate failure caused by deleting the prefix and re-adding it to escape a conflict. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Conflicts are ordinary merge conflicts with a boundary, separate the documented Git subtree 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 subtree split synthesises a history whose project root corresponds to the selected prefix. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is copying the directory to a new repository and losing meaningful history. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Split in a clean disposable rehearsal and inspect the resulting branch.

For the Split extracts prefix history chapter on Git subtree, 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 copying the directory to a new repository and losing meaningful history. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree split --prefix=lib/shared -b shared-export

Four purposeful transfer cases

Case 1: CCA app. Transfer the rule using a reusable registration 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.

Case 2: science scripts. Predict the rule using a plotting library embedded under vendor. 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.

Case 3: revision repository. Contrast the rule using shared quiz data kept under packages. 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.

Case 4: family project. Stress-test the rule using a small library contributed back upstream. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers copying the directory to a new repository and losing meaningful history.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Split in a clean disposable rehearsal and inspect the resulting branch.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Split extracts prefix history?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing copying the directory to a new repository and losing meaningful history be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny release exercise with squashed and unsquashed update histories. Include one ordinary case, one boundary and one deliberate failure caused by copying the directory to a new repository and losing meaningful history. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Split extracts prefix history, separate the documented Git subtree 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 documented split process aims to produce identical commit IDs for the same history and options, supporting later collaboration. 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 split options and expecting the same synthetic history. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Record prefix, annotate and rejoin options beside the command.

For the Repeated splits can be reproducible chapter on Git subtree, 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 split options and expecting the same synthetic history. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree split --prefix=lib/shared -b export-a
git subtree split --prefix=lib/shared -b export-b

Four purposeful transfer cases

Case 1: revision repository. Predict the rule using shared quiz data kept under packages. 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.

Case 2: family project. Contrast the rule using a small library contributed back upstream. 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.

Case 3: release exercise. Stress-test the rule using squashed and unsquashed update histories. 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.

Case 4: disposable Git laboratory. Explain the rule using local remotes, controlled prefixes and exact trees. 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.

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 split options and expecting the same synthetic history.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Record prefix, annotate and rejoin options beside the 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Repeated splits can be reproducible?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing changing split options and expecting the same synthetic history be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny disposable Git laboratory with local remotes, controlled prefixes and exact trees. Include one ordinary case, one boundary and one deliberate failure caused by changing split options and expecting the same synthetic history. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Repeated splits can be reproducible, separate the documented Git subtree 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 subtree push performs a split and pushes the resulting history to a repository ref. 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 pushing directly to an important upstream branch without reviewing the split. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Create and inspect a local split branch before the first real push.

For the Push splits and sends subtree history chapter on Git subtree, 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 pushing directly to an important upstream branch without reviewing the split. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree push --prefix=lib/shared shared contribution

Four purposeful transfer cases

Case 1: release exercise. Contrast the rule using squashed and unsquashed update histories. 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.

Case 2: disposable Git laboratory. Stress-test the rule using local remotes, controlled prefixes and exact trees. 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.

Case 3: coding assignment. Explain the rule using a shared utility folder used by two projects. 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.

Case 4: group website. Transfer the rule using a theme maintained in its own repository. 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.

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 pushing directly to an important upstream branch without reviewing the split.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Create and inspect a local split branch before the first real push.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Push splits and sends subtree history?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing pushing directly to an important upstream branch without reviewing the split be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny coding assignment with a shared utility folder used by two projects. Include one ordinary case, one boundary and one deliberate failure caused by pushing directly to an important upstream branch without reviewing the split. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Push splits and sends subtree history, separate the documented Git subtree 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

Pull merges remote subproject history into the prefix, while push exports prefix-relevant history; both operate on Git history. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is thinking in terms of copying the latest folder snapshot only. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Draw source history, main history and synthetic split history.

For the Pull and push are not symmetric file copies chapter on Git subtree, 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 thinking in terms of copying the latest folder snapshot only. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git log --graph --decorate --oneline --all

Four purposeful transfer cases

Case 1: coding assignment. Stress-test the rule using a shared utility folder used by two projects. 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.

Case 2: group website. Explain the rule using a theme maintained in its own repository. 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.

Case 3: CCA app. Transfer the rule using a reusable registration 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.

Case 4: science scripts. Predict the rule using a plotting library embedded under vendor. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers thinking in terms of copying the latest folder snapshot only.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Draw source history, main history and synthetic split history.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Pull and push are not symmetric file copies?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing thinking in terms of copying the latest folder snapshot only be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny group website with a theme maintained in its own repository. Include one ordinary case, one boundary and one deliberate failure caused by thinking in terms of copying the latest folder snapshot only. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Pull and push are not symmetric file copies, separate the documented Git subtree 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

Subtree operations add metadata trailers such as git-subtree-dir and git-subtree-split so later operations can locate prior relationships. 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 rewriting or stripping trailers without understanding their role. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect generated commit messages before rebasing or filtering history.

For the Commit trailers reconnect split ancestry chapter on Git subtree, 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 rewriting or stripping trailers without understanding their role. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git show -s --format=%B HEAD

Four purposeful transfer cases

Case 1: CCA app. Explain the rule using a reusable registration 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.

Case 2: science scripts. Transfer the rule using a plotting library embedded under vendor. 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.

Case 3: revision repository. Predict the rule using shared quiz data kept under packages. 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.

Case 4: family project. Contrast the rule using a small library contributed back upstream. 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.

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 rewriting or stripping trailers without understanding their role.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect generated commit messages before rebasing or filtering history.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Commit trailers reconnect split ancestry?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing rewriting or stripping trailers without understanding their role be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA app with a reusable registration component. Include one ordinary case, one boundary and one deliberate failure caused by rewriting or stripping trailers without understanding their role. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Commit trailers reconnect split ancestry, separate the documented Git subtree 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

Commits that mix main-project files with subtree-prefix files are harder to split, review and contribute upstream. 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 including an app refactor and shared-library change in one commit. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Stage by path and create logically separate commits.

For the Changes should be separated by project chapter on Git subtree, 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 including an app refactor and shared-library change in one commit. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git add lib/shared && git commit -m 'shared: fix parser'

Four purposeful transfer cases

Case 1: revision repository. Transfer the rule using shared quiz data kept under packages. 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.

Case 2: family project. Predict the rule using a small library contributed back upstream. 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.

Case 3: release exercise. Contrast the rule using squashed and unsquashed update histories. 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.

Case 4: disposable Git laboratory. Stress-test the rule using local remotes, controlled prefixes and exact trees. 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.

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 including an app refactor and shared-library change in one commit.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Stage by path and create logically separate commits.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Changes should be separated by project?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing including an app refactor and shared-library change in one commit be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science scripts with a plotting library embedded under vendor. Include one ordinary case, one boundary and one deliberate failure caused by including an app refactor and shared-library change in one commit. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Changes should be separated by project, separate the documented Git subtree 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 –annotate option can prefix messages created by split, helping readers distinguish projected history. 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 annotation text between repeated splits and expecting identical commit IDs. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Treat annotation as part of the reproducibility policy.

For the annotate can identify synthetic split commits chapter on Git subtree, 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 annotation text between repeated splits and expecting identical commit IDs. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree split --prefix=lib/shared --annotate='(split) ' -b export

Four purposeful transfer cases

Case 1: release exercise. Predict the rule using squashed and unsquashed update histories. 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.

Case 2: disposable Git laboratory. Contrast the rule using local remotes, controlled prefixes and exact trees. 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.

Case 3: coding assignment. Stress-test the rule using a shared utility folder used by two projects. 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.

Case 4: group website. Explain the rule using a theme maintained in its own repository. 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.

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 annotation text between repeated splits and expecting identical commit IDs.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Treat annotation as part of the reproducibility policy.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from annotate can identify synthetic split commits?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing changing annotation text between repeated splits and expecting identical commit IDs 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 shared quiz data kept under packages. Include one ordinary case, one boundary and one deliberate failure caused by changing annotation text between repeated splits and expecting identical commit IDs. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For annotate can identify synthetic split commits, separate the documented Git subtree 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

–rejoin can merge newly split history back into the main repository so later splits can search less history. 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 rejoin without wanting extra synthetic commits in the main history. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test graph shape and split performance before adopting it.

For the rejoin trades future speed for main-history commits chapter on Git subtree, 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 rejoin without wanting extra synthetic commits in the main history. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git subtree split --prefix=lib/shared --rejoin -b export

Four purposeful transfer cases

Case 1: coding assignment. Contrast the rule using a shared utility folder used by two projects. 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.

Case 2: group website. Stress-test the rule using a theme maintained in its own repository. 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.

Case 3: CCA app. Explain the rule using a reusable registration 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.

Case 4: science scripts. Transfer the rule using a plotting library embedded under vendor. 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.

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 rejoin without wanting extra synthetic commits in the main history.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test graph shape and split performance before adopting 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from rejoin trades future speed for main-history commits?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using rejoin without wanting extra synthetic commits in the main history be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family project with a small library contributed back upstream. Include one ordinary case, one boundary and one deliberate failure caused by using rejoin without wanting extra synthetic commits in the main history. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For rejoin trades future speed for main-history commits, separate the documented Git subtree 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 subtree stores project files in the main repository, while a submodule records a separate repository commit and needs its own checkout 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 choosing between them from a slogan instead of ownership and contribution needs. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare clone experience, history size, update policy and upstream workflow.

For the Subtree is not submodule chapter on Git subtree, 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 choosing between them from a slogan instead of ownership and contribution needs. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git ls-files lib/shared | head

Four purposeful transfer cases

Case 1: CCA app. Stress-test the rule using a reusable registration 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.

Case 2: science scripts. Explain the rule using a plotting library embedded under vendor. 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.

Case 3: revision repository. Transfer the rule using shared quiz data kept under packages. 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.

Case 4: family project. Predict the rule using a small library contributed back upstream. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers choosing between them from a slogan instead of ownership and contribution needs.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Compare clone experience, history size, update policy and upstream 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Subtree is not submodule?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing choosing between them from a slogan instead of ownership and contribution needs be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny release exercise with squashed and unsquashed update histories. Include one ordinary case, one boundary and one deliberate failure caused by choosing between them from a slogan instead of ownership and contribution needs. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Subtree is not submodule, separate the documented Git subtree 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

Subtree commands create commits and merges, so important work should be committed, backed up and tested before updating or exporting. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is running pull or push from a dirty, poorly understood repository. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Check status, refs and recovery commands before the operation.

For the Backups and clean state protect synchronisation chapter on Git subtree, 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 running pull or push from a dirty, poorly understood repository. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

git status --short && git branch --show-current

Four purposeful transfer cases

Case 1: revision repository. Explain the rule using shared quiz data kept under packages. 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.

Case 2: family project. Transfer the rule using a small library contributed back upstream. 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.

Case 3: release exercise. Predict the rule using squashed and unsquashed update histories. 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.

Case 4: disposable Git laboratory. Contrast the rule using local remotes, controlled prefixes and exact trees. 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.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers running pull or push from a dirty, poorly understood repository.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Check status, refs and recovery commands before the 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from Backups and clean state protect synchronisation?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing running pull or push from a dirty, poorly understood repository be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny disposable Git laboratory with local remotes, controlled prefixes and exact trees. Include one ordinary case, one boundary and one deliberate failure caused by running pull or push from a dirty, poorly understood repository. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Backups and clean state protect synchronisation, separate the documented Git subtree 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 complete lab creates local main and shared repositories, adds a prefix, updates upstream, pulls, edits locally, splits and pushes to a review branch. 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 testing only add and never rehearsing the return path. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Record trees and graphs after every transition.

For the A two-repository lab proves mastery chapter on Git subtree, 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 testing only add and never rehearsing the return path. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

tmp=$(mktemp -d)
# create local main.git and shared.git inside the disposable directory

Four purposeful transfer cases

Case 1: release exercise. Transfer the rule using squashed and unsquashed update histories. 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.

Case 2: disposable Git laboratory. Predict the rule using local remotes, controlled prefixes and exact trees. 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.

Case 3: coding assignment. Contrast the rule using a shared utility folder used by two projects. 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.

Case 4: group website. Stress-test the rule using a theme maintained in its own repository. 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.

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 testing only add and never rehearsing the return path.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Record trees and graphs after every transition.” 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 subtree syntax. For this chapter, useful prompts are: “What did you expect from A two-repository lab proves mastery?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing testing only add and never rehearsing the return path be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny coding assignment with a shared utility folder used by two projects. Include one ordinary case, one boundary and one deliberate failure caused by testing only add and never rehearsing the return path. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A two-repository lab proves mastery, separate the documented Git subtree 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

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.

1. coding assignment: model, boundary and recovery

Create a small coding assignment using a shared utility folder used by two projects. Combine “A subtree is ordinary tracked content” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. group website: model, boundary and recovery

Create a small group website using a theme maintained in its own repository. Combine “Add imports a project once” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. CCA app: model, boundary and recovery

Create a small CCA app using a reusable registration component. Combine “Unsquashed mode preserves joined history” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. science scripts: model, boundary and recovery

Create a small science scripts using a plotting library embedded under vendor. Combine “Split extracts prefix history” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. revision repository: model, boundary and recovery

Create a small revision repository using shared quiz data kept under packages. Combine “Pull and push are not symmetric file copies” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. family project: model, boundary and recovery

Create a small family project using a small library contributed back upstream. Combine “annotate can identify synthetic split commits” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. release exercise: model, boundary and recovery

Create a small release exercise using squashed and unsquashed update histories. Combine “Backups and clean state protect synchronisation” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. disposable Git laboratory: model, boundary and recovery

Create a small disposable Git laboratory using local remotes, controlled prefixes and exact trees. Combine “The prefix defines the ownership boundary” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

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.

Official and supporting references

• Primary technical documentation for Git subtree
• eduKatePunggol: How Studying Works

Return to contents