PUNGGOL TUITION · PRACTICAL MASTERY GUIDE

If a learner has a .pack file and assumes “unpack” means double-clicking or passing the filename as an argument, the real gap is understanding Git plumbing: repository context, binary standard input, existing-object skipping and post-write verification.

The practical rule is that git unpack-objects reads a pack stream from standard input and writes missing objects as loose objects into the selected repository. If the objects already exist—including in an installed pack—it writes nothing. Dry run, strict checking, size limits, quarantine and object-level verification turn the command from a guess into a controlled workflow.

This guide treats Git unpack-objects as a reasoning skill. It begins with the governing model, moves through worked examples and diagnostic routes, and ends with transfer cases, practice with explained answers, parent decisions and FAQs. The examples are proposed home or lesson activities; they are not claims about a physical Punggol branch, school affiliation, timetable, class size, fee or guaranteed result.

For a Punggol family, the practical aim is simple: a learner should be able to use a short study block before schoolwork, after CCA, or during a weekend library session without needing a large project. Each chapter is designed so the smallest useful example can be completed, discussed and saved as a test fixture.

The official technical reference for this article is Official git-unpack-objects manual. Where the feature is version-sensitive or still developing, the article states that boundary explicitly. Examples were independently checked against the runtime or specification named in the reference section.

Choose a reading route

If the immediate concern is “I can copy the syntax but I cannot explain the result”, use the first route. If a real project is already failing, use the diagnostic route. Parents can use the final route to decide whether more practice, a smaller prerequisite or a different example is needed. For the wider learning framework, see How Studying Works.

Start from the model: Chapters 1–4. Begin with What git unpack-objects does and continue in order to Why unpacking a repository’s own pack may do nothing.

Diagnose a confusing result: Chapters 5–8. Begin with Building a safe fixture pack and continue in order to Input-size guard with –max-input-size.

Build reliable examples: Chapters 9–12. Begin with Quiet mode with -q and continue in order to Verifying object identity after unpacking.

Transfer to real work: Chapters 13–16. Begin with Post-write integrity with git fsck and continue in order to Quarantine in a disposable repository.

Decide and teach: Chapters 17–20. Begin with Object format compatibility and continue in order to Choosing unpack-objects for the right job.

Open the full 20-chapter index

1. 1. What git unpack-objects does
2. 2. The target repository determines what can be written
3. 3. Existing objects are skipped
4. 4. Why unpacking a repository’s own pack may do nothing
5. 5. Building a safe fixture pack
6. 6. Dry-run inspection with -n
7. 7. Strict validation with –strict
8. 8. Input-size guard with –max-input-size
9. 9. Quiet mode with -q
10. 10. Recovery mode with -r
11. 11. Corruption boundaries and binary handling
12. 12. Verifying object identity after unpacking
13. 13. Post-write integrity with git fsck
14. 14. unpack-objects versus index-pack
15. 15. unpack-objects versus cat-file
16. 16. Quarantine in a disposable repository
17. 17. Object format compatibility
18. 18. Standard input must remain binary-safe
19. 19. Cleanup and repacking after recovery
20. 20. Choosing unpack-objects for the right job

CHAPTER 1 OF 20 · Back to contents

1. What git unpack-objects does

The short answer: git unpack-objects reads a pack from standard input and expands eligible objects into loose object storage. The governing rule is: The command consumes binary pack data from stdin; it is not given a pack filename as a normal positional argument.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Git parses the pack stream, validates entries under the selected options and writes objects that are not already present in the target repository. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the what git unpack-objects does example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

git unpack-objects < objects.pack

Expected result and reasoning. In a suitable receiving repository, missing packed objects become loose objects. Standard output is normally quiet. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Running git unpack-objects objects.pack mistakes a stdin filter for a filename-taking command. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which repository is the target, and where is the pack byte stream coming from?”

• Evidence to collect: GIT_DIR, stdin source and object counts
• Variable to hold constant: the surrounding setup, so the comparison isolates what git unpack-objects does.
• Variable to change: pipe with cat instead of redirection
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For what git unpack-objects does, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a disposable source repository. Apply what git unpack-objects does in a disposable source repository. The central question is whether the same rule still governs after the context changes. git unpack-objects reads a pack from standard input and expands eligible objects into loose object storage. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The command consumes binary pack data from stdin; it is not given a pack filename as a normal positional argument.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a damaged transfer copy. Apply what git unpack-objects does in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. git unpack-objects reads a pack from standard input and expands eligible objects into loose object storage. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The command consumes binary pack data from stdin; it is not given a pack filename as a normal positional argument.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a backup pack inspection. Apply what git unpack-objects does in a backup pack inspection. The central question is whether the same rule still governs after the context changes. git unpack-objects reads a pack from standard input and expands eligible objects into loose object storage. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The command consumes binary pack data from stdin; it is not given a pack filename as a normal positional argument.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a forensic recovery exercise. Apply what git unpack-objects does in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. git unpack-objects reads a pack from standard input and expands eligible objects into loose object storage. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The command consumes binary pack data from stdin; it is not given a pack filename as a normal positional argument.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Write two equivalent safe stdin pipelines. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Use input redirection or a binary-safe producer such as cat objects.pack | git unpack-objects. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to identify producer, pipe and repository separately. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain what git unpack-objects does, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Contents · Full contents · Next: The target repository determines what can be written →

CHAPTER 2 OF 20 · Back to contents

2. The target repository determines what can be written

The short answer: Objects are installed into the object database selected by the current repository environment. The governing rule is: Always confirm the receiving GIT_DIR before unpacking.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The pack itself carries objects, but repository discovery determines where loose objects would be stored and what objects already exist. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the the target repository determines what can be written example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=/tmp/receiver.git git unpack-objects < objects.pack

Expected result and reasoning. The command addresses /tmp/receiver.git rather than an unrelated working tree. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Running from a familiar shell directory without checking repository context risks writing to the wrong object database. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What does git rev-parse –git-dir report for this command context?”

• Evidence to collect: absolute git directory and object count
• Variable to hold constant: the surrounding setup, so the comparison isolates the target repository determines what can be written.
• Variable to change: change GIT_DIR to a disposable bare repository
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For the target repository determines what can be written, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an empty receiving repository. Apply the target repository determines what can be written in an empty receiving repository. The central question is whether the same rule still governs after the context changes. Objects are installed into the object database selected by the current repository environment. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Always confirm the receiving GIT_DIR before unpacking.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a CI quarantine directory. Apply the target repository determines what can be written in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. Objects are installed into the object database selected by the current repository environment. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Always confirm the receiving GIT_DIR before unpacking.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a SHA-256 test repository. Apply the target repository determines what can be written in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. Objects are installed into the object database selected by the current repository environment. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Always confirm the receiving GIT_DIR before unpacking.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a scripted stdin pipeline. Apply the target repository determines what can be written in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. Objects are installed into the object database selected by the current repository environment. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Always confirm the receiving GIT_DIR before unpacking.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Prepare an empty bare receiver and show the command that targets it explicitly. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Create it with git init –bare, resolve its absolute path, and pass GIT_DIR for the unpack operation. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Make repository identity the first line of every recovery note. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain the target repository determines what can be written, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: What git unpack-objects does · Full contents · Next: Existing objects are skipped →

CHAPTER 3 OF 20 · Back to contents

3. Existing objects are skipped

The short answer: git unpack-objects does not write objects that already exist in the repository. The governing rule is: Object identity makes duplicate installation unnecessary.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Before creating a loose object, Git can see that the target object database already has it, whether loose or reachable in packs. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the existing objects are skipped example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

git count-objects -v
git unpack-objects < objects.pack
git count-objects -v

Expected result and reasoning. In a repository already containing all objects, loose counts need not increase. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Interpreting no new files as command failure ignores the documented skip behaviour. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Did the target already possess every object in the input pack?”

• Evidence to collect: before/after counts and cat-file checks
• Variable to hold constant: the surrounding setup, so the comparison isolates existing objects are skipped.
• Variable to change: use a new empty receiver
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For existing objects are skipped, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a damaged transfer copy. Apply existing objects are skipped in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. git unpack-objects does not write objects that already exist in the repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Object identity makes duplicate installation unnecessary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a backup pack inspection. Apply existing objects are skipped in a backup pack inspection. The central question is whether the same rule still governs after the context changes. git unpack-objects does not write objects that already exist in the repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Object identity makes duplicate installation unnecessary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a forensic recovery exercise. Apply existing objects are skipped in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. git unpack-objects does not write objects that already exist in the repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Object identity makes duplicate installation unnecessary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a disposable source repository. Apply existing objects are skipped in a disposable source repository. The central question is whether the same rule still governs after the context changes. git unpack-objects does not write objects that already exist in the repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Object identity makes duplicate installation unnecessary.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Compare the same pack in its source repository and an empty receiver. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The source commonly writes nothing because objects already exist; the empty receiver writes missing loose objects. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Require evidence of object presence before labelling quiet output a failure. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain existing objects are skipped, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: The target repository determines what can be written · Full contents · Next: Why unpacking a repository’s own pack may do nothing →

CHAPTER 4 OF 20 · Back to contents

4. Why unpacking a repository’s own pack may do nothing

The short answer: When the pack belongs to the same repository, its objects are already in that object database. The governing rule is: The manual explicitly notes that nothing will be unpacked in this case.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Packed objects count as existing objects, so unpack-objects has no reason to duplicate them as loose copies. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the why unpacking a repository’s own pack may do nothing example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

git unpack-objects < .git/objects/pack/pack-example.pack

Expected result and reasoning. If that exact pack is already installed in the current repository, no objects are expanded. Use a disposable copy for experiments. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Expecting the command to convert an installed pack into loose duplicates contradicts the skip rule. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the input pack already part of the target object database?”

• Evidence to collect: pack path, target git dir and before/after counts
• Variable to hold constant: the surrounding setup, so the comparison isolates why unpacking a repository’s own pack may do nothing.
• Variable to change: copy the pack to an empty bare repository context
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For why unpacking a repository’s own pack may do nothing, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a CI quarantine directory. Apply why unpacking a repository’s own pack may do nothing in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. When the pack belongs to the same repository, its objects are already in that object database. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The manual explicitly notes that nothing will be unpacked in this case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a SHA-256 test repository. Apply why unpacking a repository’s own pack may do nothing in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. When the pack belongs to the same repository, its objects are already in that object database. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The manual explicitly notes that nothing will be unpacked in this case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a scripted stdin pipeline. Apply why unpacking a repository’s own pack may do nothing in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. When the pack belongs to the same repository, its objects are already in that object database. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The manual explicitly notes that nothing will be unpacked in this case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an empty receiving repository. Apply why unpacking a repository’s own pack may do nothing in an empty receiving repository. The central question is whether the same rule still governs after the context changes. When the pack belongs to the same repository, its objects are already in that object database. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The manual explicitly notes that nothing will be unpacked in this case.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Explain why “pack exists” and “loose object absent” do not imply unpacking will occur. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Git considers the object present in packed form, so it is skipped. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

This is the central ownership check before every example. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain why unpacking a repository’s own pack may do nothing, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Existing objects are skipped · Full contents · Next: Building a safe fixture pack →

CHAPTER 5 OF 20 · Back to contents

5. Building a safe fixture pack

The short answer: A controlled pack can be produced from a tiny disposable source repository. The governing rule is: Generate fixtures from known commits rather than borrowing an unknown production pack.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

git pack-objects –stdout can emit reachable objects as a binary stream while rev-list supplies the object names. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the building a safe fixture pack example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

git -C source rev-list --objects --all | git -C source pack-objects --stdout > fixture.pack

Expected result and reasoning. The file begins with a Git pack stream containing the source repository’s reachable objects. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using shell text tools on the binary pack can corrupt it. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Were object names generated from the intended source, and was stdout redirected without text transformation?”

• Evidence to collect: source commit ID, pack size and checksum
• Variable to hold constant: the surrounding setup, so the comparison isolates building a safe fixture pack.
• Variable to change: create one additional commit and regenerate
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For building a safe fixture pack, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a backup pack inspection. Apply building a safe fixture pack in a backup pack inspection. The central question is whether the same rule still governs after the context changes. A controlled pack can be produced from a tiny disposable source repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Generate fixtures from known commits rather than borrowing an unknown production pack.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a forensic recovery exercise. Apply building a safe fixture pack in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. A controlled pack can be produced from a tiny disposable source repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Generate fixtures from known commits rather than borrowing an unknown production pack.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a disposable source repository. Apply building a safe fixture pack in a disposable source repository. The central question is whether the same rule still governs after the context changes. A controlled pack can be produced from a tiny disposable source repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Generate fixtures from known commits rather than borrowing an unknown production pack.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a damaged transfer copy. Apply building a safe fixture pack in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. A controlled pack can be produced from a tiny disposable source repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Generate fixtures from known commits rather than borrowing an unknown production pack.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Create a one-commit fixture and record its HEAD and pack checksum. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The record ties the binary fixture to a known graph and supports later verification in the receiver. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Use only disposable repositories for this exercise. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain building a safe fixture pack, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Why unpacking a repository’s own pack may do nothing · Full contents · Next: Dry-run inspection with -n →

CHAPTER 6 OF 20 · Back to contents

6. Dry-run inspection with -n

The short answer: The -n option parses the pack without writing objects. The governing rule is: Use dry run to check that input can be processed before mutating a receiver.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The manual describes -n as a dry run. It is a validation step, not proof that a later write has already occurred. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the dry-run inspection with -n example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git unpack-objects -n < fixture.pack

Expected result and reasoning. A valid fixture exits successfully while receiver object counts stay unchanged. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Reading a successful dry run as “objects installed” confuses validation with mutation. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Did counts and files remain unchanged after -n?”

• Evidence to collect: exit status and before/after object counts
• Variable to hold constant: the surrounding setup, so the comparison isolates dry-run inspection with -n.
• Variable to change: run again without -n in the disposable receiver
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For dry-run inspection with -n, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a SHA-256 test repository. Apply dry-run inspection with -n in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. The -n option parses the pack without writing objects. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use dry run to check that input can be processed before mutating a receiver.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a scripted stdin pipeline. Apply dry-run inspection with -n in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. The -n option parses the pack without writing objects. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use dry run to check that input can be processed before mutating a receiver.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an empty receiving repository. Apply dry-run inspection with -n in an empty receiving repository. The central question is whether the same rule still governs after the context changes. The -n option parses the pack without writing objects. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use dry run to check that input can be processed before mutating a receiver.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a CI quarantine directory. Apply dry-run inspection with -n in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. The -n option parses the pack without writing objects. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use dry run to check that input can be processed before mutating a receiver.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Compare observable state after dry run and real unpack. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Dry run checks processing; normal mode writes missing loose objects. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask for state evidence, not just exit code. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain dry-run inspection with -n, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Building a safe fixture pack · Full contents · Next: Strict validation with –strict →

CHAPTER 7 OF 20 · Back to contents

7. Strict validation with –strict

The short answer: –strict adds checks for broken content or links. The governing rule is: Use strict mode when acceptance requires stronger object and link validation.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The option rejects objects with broken content or links rather than accepting them into the ordinary flow. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the strict validation with –strict example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git unpack-objects --strict < fixture.pack

Expected result and reasoning. A valid known fixture should pass; intentionally broken data should be rejected. Exact diagnostics depend on corruption. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling –strict a malware scanner or complete repository audit overstates its contract. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which integrity conditions does this option add, and what still needs git fsck?”

• Evidence to collect: exit status, stderr and later fsck
• Variable to hold constant: the surrounding setup, so the comparison isolates strict validation with –strict.
• Variable to change: compare normal dry run with strict dry run
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For strict validation with –strict, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a forensic recovery exercise. Apply strict validation with –strict in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. –strict adds checks for broken content or links. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use strict mode when acceptance requires stronger object and link validation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a disposable source repository. Apply strict validation with –strict in a disposable source repository. The central question is whether the same rule still governs after the context changes. –strict adds checks for broken content or links. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use strict mode when acceptance requires stronger object and link validation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a damaged transfer copy. Apply strict validation with –strict in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. –strict adds checks for broken content or links. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use strict mode when acceptance requires stronger object and link validation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a backup pack inspection. Apply strict validation with –strict in a backup pack inspection. The central question is whether the same rule still governs after the context changes. –strict adds checks for broken content or links. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use strict mode when acceptance requires stronger object and link validation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. State why a recovery workflow might choose –strict. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. It raises acceptance requirements for broken content or links, while post-write repository verification remains valuable. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Teach precise scope for safety flags. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain strict validation with –strict, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Dry-run inspection with -n · Full contents · Next: Input-size guard with –max-input-size →

CHAPTER 8 OF 20 · Back to contents

8. Input-size guard with –max-input-size

The short answer: –max-input-size rejects an input pack larger than the stated byte limit. The governing rule is: Set a limit from an explicit resource policy, not an invented universal number.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The guard can stop unexpectedly large input before a recovery tool consumes unbounded data. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the input-size guard with –max-input-size example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git unpack-objects --max-input-size=1024 < fixture.pack

Expected result and reasoning. A pack larger than 1024 bytes is rejected; a smaller one may proceed subject to other validation. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Confusing bytes with object count gives a false capacity model. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What is the fixture byte size, and what policy selected the limit?”

• Evidence to collect: stat byte count, limit and exit status
• Variable to hold constant: the surrounding setup, so the comparison isolates input-size guard with –max-input-size.
• Variable to change: set the limit just below and just above actual size
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For input-size guard with –max-input-size, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a scripted stdin pipeline. Apply input-size guard with –max-input-size in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. –max-input-size rejects an input pack larger than the stated byte limit. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Set a limit from an explicit resource policy, not an invented universal number.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an empty receiving repository. Apply input-size guard with –max-input-size in an empty receiving repository. The central question is whether the same rule still governs after the context changes. –max-input-size rejects an input pack larger than the stated byte limit. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Set a limit from an explicit resource policy, not an invented universal number.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a CI quarantine directory. Apply input-size guard with –max-input-size in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. –max-input-size rejects an input pack larger than the stated byte limit. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Set a limit from an explicit resource policy, not an invented universal number.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a SHA-256 test repository. Apply input-size guard with –max-input-size in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. –max-input-size rejects an input pack larger than the stated byte limit. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Set a limit from an explicit resource policy, not an invented universal number.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Design a boundary test around the known pack size. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Use size-1 to demonstrate rejection and size or larger to permit processing, while retaining other checks. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Require units and a reason for every threshold. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain input-size guard with –max-input-size, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Strict validation with –strict · Full contents · Next: Quiet mode with -q →

CHAPTER 9 OF 20 · Back to contents

9. Quiet mode with -q

The short answer: The -q option suppresses progress output. The governing rule is: Quiet mode changes reporting, not object semantics.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

It is useful in controlled scripts where exit status and separate logs capture the outcome. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the quiet mode with -q example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git unpack-objects -q < fixture.pack

Expected result and reasoning. The repository mutation is the same as normal mode; the console is quieter. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating silence as success without checking exit status is unsafe. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Where will the script record success, failure and repository identity?”

• Evidence to collect: exit code and structured log
• Variable to hold constant: the surrounding setup, so the comparison isolates quiet mode with -q.
• Variable to change: remove -q and compare output
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For quiet mode with -q, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a disposable source repository. Apply quiet mode with -q in a disposable source repository. The central question is whether the same rule still governs after the context changes. The -q option suppresses progress output. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Quiet mode changes reporting, not object semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a damaged transfer copy. Apply quiet mode with -q in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. The -q option suppresses progress output. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Quiet mode changes reporting, not object semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a backup pack inspection. Apply quiet mode with -q in a backup pack inspection. The central question is whether the same rule still governs after the context changes. The -q option suppresses progress output. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Quiet mode changes reporting, not object semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a forensic recovery exercise. Apply quiet mode with -q in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. The -q option suppresses progress output. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Quiet mode changes reporting, not object semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Write a wrapper that captures exit status after quiet mode. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Check the command result and verify objects; do not use lack of output as proof. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Quiet automation needs stronger explicit observability. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain quiet mode with -q, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Input-size guard with –max-input-size · Full contents · Next: Recovery mode with -r →

CHAPTER 10 OF 20 · Back to contents

10. Recovery mode with -r

The short answer: The -r option attempts to continue after a corrupt object so later recoverable objects can be considered. The governing rule is: It is a best-effort recovery mode, not a declaration that the result is complete.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Normal behaviour stops at corruption. Recovery mode changes the continuation policy and therefore requires careful post-run auditing. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the recovery mode with -r example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git unpack-objects -r < damaged.pack

Expected result and reasoning. The command may recover some objects after corruption, but diagnostics and completeness must be examined. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using -r in a routine trusted import can hide the seriousness of damaged input. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What objects were expected, which were recovered and which failed?”

• Evidence to collect: stderr, expected object list and fsck report
• Variable to hold constant: the surrounding setup, so the comparison isolates recovery mode with -r.
• Variable to change: run normal mode on a copy for comparison
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For recovery mode with -r, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an empty receiving repository. Apply recovery mode with -r in an empty receiving repository. The central question is whether the same rule still governs after the context changes. The -r option attempts to continue after a corrupt object so later recoverable objects can be considered. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “It is a best-effort recovery mode, not a declaration that the result is complete.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a CI quarantine directory. Apply recovery mode with -r in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. The -r option attempts to continue after a corrupt object so later recoverable objects can be considered. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “It is a best-effort recovery mode, not a declaration that the result is complete.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a SHA-256 test repository. Apply recovery mode with -r in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. The -r option attempts to continue after a corrupt object so later recoverable objects can be considered. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “It is a best-effort recovery mode, not a declaration that the result is complete.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a scripted stdin pipeline. Apply recovery mode with -r in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. The -r option attempts to continue after a corrupt object so later recoverable objects can be considered. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “It is a best-effort recovery mode, not a declaration that the result is complete.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Describe when -r is justified. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Use it in a quarantined forensic recovery attempt where partial recovery is valuable and incompleteness is explicitly tracked. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Separate recovery goals from normal transfer goals. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain recovery mode with -r, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Quiet mode with -q · Full contents · Next: Corruption boundaries and binary handling →

CHAPTER 11 OF 20 · Back to contents

11. Corruption boundaries and binary handling

The short answer: A pack is a structured binary format; truncation or byte changes can invalidate headers, entries or checksums. The governing rule is: Preserve the original and corrupt only disposable copies for learning.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Different damage locations can produce different diagnostics and may affect whether later entries are recoverable. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the corruption boundaries and binary handling example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

cp fixture.pack damaged.pack
truncate -s -1 damaged.pack

Expected result and reasoning. The truncated copy should fail validation or unpacking; the original checksum remains available for comparison. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Editing binary data with a text editor can create uncontrolled changes that teach little. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Exactly how was the copy changed, and was the original preserved?”

• Evidence to collect: checksums, sizes and stderr
• Variable to hold constant: the surrounding setup, so the comparison isolates corruption boundaries and binary handling.
• Variable to change: truncate at a documented different offset in another copy
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For corruption boundaries and binary handling, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a damaged transfer copy. Apply corruption boundaries and binary handling in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. A pack is a structured binary format; truncation or byte changes can invalidate headers, entries or checksums. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Preserve the original and corrupt only disposable copies for learning.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a backup pack inspection. Apply corruption boundaries and binary handling in a backup pack inspection. The central question is whether the same rule still governs after the context changes. A pack is a structured binary format; truncation or byte changes can invalidate headers, entries or checksums. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Preserve the original and corrupt only disposable copies for learning.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a forensic recovery exercise. Apply corruption boundaries and binary handling in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. A pack is a structured binary format; truncation or byte changes can invalidate headers, entries or checksums. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Preserve the original and corrupt only disposable copies for learning.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a disposable source repository. Apply corruption boundaries and binary handling in a disposable source repository. The central question is whether the same rule still governs after the context changes. A pack is a structured binary format; truncation or byte changes can invalidate headers, entries or checksums. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Preserve the original and corrupt only disposable copies for learning.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Create a damage log for one-byte truncation. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Record original hash and size, copy hash and size, exact command, result and receiver state. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Never practise corruption on the sole copy of meaningful data. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain corruption boundaries and binary handling, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Recovery mode with -r · Full contents · Next: Verifying object identity after unpacking →

CHAPTER 12 OF 20 · Back to contents

12. Verifying object identity after unpacking

The short answer: Successful unpack should be followed by checks that expected object IDs exist in the receiver. The governing rule is: Use git cat-file -e and type queries against a known object list.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Object IDs from the source fixture provide stable verification targets when repository object format matches. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the verifying object identity after unpacking example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git cat-file -e "$oid^{object}"
GIT_DIR=receiver.git git cat-file -t "$oid"

Expected result and reasoning. The existence check exits successfully and the type query reports commit, tree, blob or tag for an installed object. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Counting loose files alone does not prove the specific expected graph arrived. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Can each expected object ID be resolved with the expected type?”

• Evidence to collect: OID list and cat-file results
• Variable to hold constant: the surrounding setup, so the comparison isolates verifying object identity after unpacking.
• Variable to change: remove one expected ID from the verification list to show coverage loss
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For verifying object identity after unpacking, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a CI quarantine directory. Apply verifying object identity after unpacking in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. Successful unpack should be followed by checks that expected object IDs exist in the receiver. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use git cat-file -e and type queries against a known object list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a SHA-256 test repository. Apply verifying object identity after unpacking in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. Successful unpack should be followed by checks that expected object IDs exist in the receiver. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use git cat-file -e and type queries against a known object list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a scripted stdin pipeline. Apply verifying object identity after unpacking in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. Successful unpack should be followed by checks that expected object IDs exist in the receiver. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use git cat-file -e and type queries against a known object list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an empty receiving repository. Apply verifying object identity after unpacking in an empty receiving repository. The central question is whether the same rule still governs after the context changes. Successful unpack should be followed by checks that expected object IDs exist in the receiver. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use git cat-file -e and type queries against a known object list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Verify the fixture’s commit, tree and one blob. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. All named objects should exist and report the recorded types; a complete list provides stronger assurance than one sample. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask learners to connect IDs to graph roles. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain verifying object identity after unpacking, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Corruption boundaries and binary handling · Full contents · Next: Post-write integrity with git fsck →

CHAPTER 13 OF 20 · Back to contents

13. Post-write integrity with git fsck

The short answer: git fsck inspects object connectivity and validity in the receiving repository. The governing rule is: Run it after a recovery or transfer and interpret dangling versus missing or corrupt reports carefully.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

An empty bare receiver may contain unpacked objects that are not referenced by refs, so dangling or unreachable reports can be expected even when objects are valid. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the post-write integrity with git fsck example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git fsck --full --no-reflogs

Expected result and reasoning. The command should not report corrupt or missing objects for a complete fixture; it may report dangling objects if no refs point to the commit. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating every dangling object as corruption misreads reachability diagnostics. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the finding about validity, missing connectivity or lack of refs?”

• Evidence to collect: full fsck output and receiver refs
• Variable to hold constant: the surrounding setup, so the comparison isolates post-write integrity with git fsck.
• Variable to change: create a ref to the imported commit and rerun
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For post-write integrity with git fsck, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a backup pack inspection. Apply post-write integrity with git fsck in a backup pack inspection. The central question is whether the same rule still governs after the context changes. git fsck inspects object connectivity and validity in the receiving repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Run it after a recovery or transfer and interpret dangling versus missing or corrupt reports carefully.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a forensic recovery exercise. Apply post-write integrity with git fsck in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. git fsck inspects object connectivity and validity in the receiving repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Run it after a recovery or transfer and interpret dangling versus missing or corrupt reports carefully.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a disposable source repository. Apply post-write integrity with git fsck in a disposable source repository. The central question is whether the same rule still governs after the context changes. git fsck inspects object connectivity and validity in the receiving repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Run it after a recovery or transfer and interpret dangling versus missing or corrupt reports carefully.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a damaged transfer copy. Apply post-write integrity with git fsck in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. git fsck inspects object connectivity and validity in the receiving repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Run it after a recovery or transfer and interpret dangling versus missing or corrupt reports carefully.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Explain how adding refs changes reachability without changing object bytes. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A ref can make the commit graph reachable; the underlying unpacked objects remain the same. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Teach classification of diagnostics rather than fear of any warning word. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain post-write integrity with git fsck, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Verifying object identity after unpacking · Full contents · Next: unpack-objects versus index-pack →

CHAPTER 14 OF 20 · Back to contents

14. unpack-objects versus index-pack

The short answer: index-pack builds an index for a pack and is usually the appropriate tool for installing a pack as a pack. The governing rule is: Choose between loose expansion and keeping packed storage based on the job.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

unpack-objects is plumbing for expanding missing objects; index-pack verifies and indexes pack storage. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the unpack-objects versus index-pack example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

git index-pack --stdin < fixture.pack

Expected result and reasoning. In the right mode and repository, index-pack handles the pack as packed storage rather than expanding each object loose. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using unpack-objects for every pack import can be inefficient and contrary to the desired storage form. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Do I need loose recovery material or an indexed pack?”

• Evidence to collect: desired storage and repository state
• Variable to hold constant: the surrounding setup, so the comparison isolates unpack-objects versus index-pack.
• Variable to change: run both in separate disposable receivers and compare count-objects -v
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For unpack-objects versus index-pack, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a SHA-256 test repository. Apply unpack-objects versus index-pack in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. index-pack builds an index for a pack and is usually the appropriate tool for installing a pack as a pack. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Choose between loose expansion and keeping packed storage based on the job.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a scripted stdin pipeline. Apply unpack-objects versus index-pack in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. index-pack builds an index for a pack and is usually the appropriate tool for installing a pack as a pack. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Choose between loose expansion and keeping packed storage based on the job.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an empty receiving repository. Apply unpack-objects versus index-pack in an empty receiving repository. The central question is whether the same rule still governs after the context changes. index-pack builds an index for a pack and is usually the appropriate tool for installing a pack as a pack. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Choose between loose expansion and keeping packed storage based on the job.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a CI quarantine directory. Apply unpack-objects versus index-pack in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. index-pack builds an index for a pack and is usually the appropriate tool for installing a pack as a pack. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Choose between loose expansion and keeping packed storage based on the job.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Choose a tool for a large normal pack transfer and a small forensic loose-object recovery. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. index-pack suits the normal packed case; unpack-objects can suit controlled loose expansion or recovery workflows. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Selection is part of mastery; plumbing commands are not interchangeable. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain unpack-objects versus index-pack, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Post-write integrity with git fsck · Full contents · Next: unpack-objects versus cat-file →

CHAPTER 15 OF 20 · Back to contents

15. unpack-objects versus cat-file

The short answer: cat-file inspects objects that already exist; unpack-objects ingests a pack stream. The governing rule is: Use inspection and ingestion as separate steps in a verified workflow.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

After unpacking, cat-file can confirm type, size or content of named objects without changing storage. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the unpack-objects versus cat-file example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git cat-file -s "$oid"

Expected result and reasoning. The size query reports the decompressed object content size for an existing object. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Expecting cat-file to import a missing pack confuses read and write roles. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the object already addressable in this repository?”

• Evidence to collect: cat-file exit status and object ID
• Variable to hold constant: the surrounding setup, so the comparison isolates unpack-objects versus cat-file.
• Variable to change: query before and after unpacking in an empty receiver
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For unpack-objects versus cat-file, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a forensic recovery exercise. Apply unpack-objects versus cat-file in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. cat-file inspects objects that already exist; unpack-objects ingests a pack stream. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use inspection and ingestion as separate steps in a verified workflow.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a disposable source repository. Apply unpack-objects versus cat-file in a disposable source repository. The central question is whether the same rule still governs after the context changes. cat-file inspects objects that already exist; unpack-objects ingests a pack stream. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use inspection and ingestion as separate steps in a verified workflow.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a damaged transfer copy. Apply unpack-objects versus cat-file in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. cat-file inspects objects that already exist; unpack-objects ingests a pack stream. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use inspection and ingestion as separate steps in a verified workflow.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a backup pack inspection. Apply unpack-objects versus cat-file in a backup pack inspection. The central question is whether the same rule still governs after the context changes. cat-file inspects objects that already exist; unpack-objects ingests a pack stream. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use inspection and ingestion as separate steps in a verified workflow.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Show the change in cat-file -e result across the write. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. It fails before the object exists and succeeds after successful unpacking. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

This makes mutation evidence concrete without opening internal files manually. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain unpack-objects versus cat-file, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: unpack-objects versus index-pack · Full contents · Next: Quarantine in a disposable repository →

CHAPTER 16 OF 20 · Back to contents

16. Quarantine in a disposable repository

The short answer: Unknown or damaged input should be processed away from valuable repositories. The governing rule is: Use a new temporary bare repository, explicit GIT_DIR and recorded limits.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Quarantine reduces the blast radius and makes object counts, fsck output and cleanup easy to interpret. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the quarantine in a disposable repository example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

tmp=$(mktemp -d)
git init --bare "$tmp/receiver.git"
GIT_DIR="$tmp/receiver.git" git unpack-objects -n < fixture.pack

Expected result and reasoning. The dry run addresses only the disposable repository. A later authorised write can use the same explicit target. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Running a first experiment in a production repository because Git objects are content-addressed ignores operational risk. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Can the entire receiver be discarded without losing user work?”

• Evidence to collect: temporary path and explicit command context
• Variable to hold constant: the surrounding setup, so the comparison isolates quarantine in a disposable repository.
• Variable to change: repeat with a valuable repository path only as a thought experiment
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For quarantine in a disposable repository, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a scripted stdin pipeline. Apply quarantine in a disposable repository in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. Unknown or damaged input should be processed away from valuable repositories. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use a new temporary bare repository, explicit GIT_DIR and recorded limits.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an empty receiving repository. Apply quarantine in a disposable repository in an empty receiving repository. The central question is whether the same rule still governs after the context changes. Unknown or damaged input should be processed away from valuable repositories. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use a new temporary bare repository, explicit GIT_DIR and recorded limits.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a CI quarantine directory. Apply quarantine in a disposable repository in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. Unknown or damaged input should be processed away from valuable repositories. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use a new temporary bare repository, explicit GIT_DIR and recorded limits.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a SHA-256 test repository. Apply quarantine in a disposable repository in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. Unknown or damaged input should be processed away from valuable repositories. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use a new temporary bare repository, explicit GIT_DIR and recorded limits.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Draft a quarantine checklist. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Preserve original; checksum input; create disposable receiver; dry run; size limit; strict check; real unpack if justified; verify IDs; fsck; document cleanup. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

This is the default family-laptop practice: small, reversible and explicit. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain quarantine in a disposable repository, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: unpack-objects versus cat-file · Full contents · Next: Object format compatibility →

CHAPTER 17 OF 20 · Back to contents

17. Object format compatibility

The short answer: Repositories can use different object hash formats, and object IDs are meaningful within that format. The governing rule is: Record the source and receiver object format before assuming compatibility.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Modern Git supports SHA-1 and experimental/selected SHA-256 repositories. A fixture and receiver should be created with compatible expectations. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the object format compatibility example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

git -C source rev-parse --show-object-format
git --git-dir=receiver.git rev-parse --show-object-format

Expected result and reasoning. The two commands report the object format used by each repository. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming every forty- or sixty-four-character string can be imported without format context is unsafe. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Do source and receiver report the same object format?”

• Evidence to collect: both format names and source OIDs
• Variable to hold constant: the surrounding setup, so the comparison isolates object format compatibility.
• Variable to change: create a disposable SHA-256 repository if supported
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For object format compatibility, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a disposable source repository. Apply object format compatibility in a disposable source repository. The central question is whether the same rule still governs after the context changes. Repositories can use different object hash formats, and object IDs are meaningful within that format. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Record the source and receiver object format before assuming compatibility.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a damaged transfer copy. Apply object format compatibility in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. Repositories can use different object hash formats, and object IDs are meaningful within that format. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Record the source and receiver object format before assuming compatibility.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a backup pack inspection. Apply object format compatibility in a backup pack inspection. The central question is whether the same rule still governs after the context changes. Repositories can use different object hash formats, and object IDs are meaningful within that format. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Record the source and receiver object format before assuming compatibility.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a forensic recovery exercise. Apply object format compatibility in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. Repositories can use different object hash formats, and object IDs are meaningful within that format. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Record the source and receiver object format before assuming compatibility.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Add object format to the fixture manifest. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Record it beside Git version, HEAD, pack size and checksum before transfer. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Versioned tooling includes storage format, not only command syntax. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain object format compatibility, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Quarantine in a disposable repository · Full contents · Next: Standard input must remain binary-safe →

CHAPTER 18 OF 20 · Back to contents

18. Standard input must remain binary-safe

The short answer: The pack stream must pass through tools that preserve bytes exactly. The governing rule is: Avoid text decoding, newline conversion or logging the raw stream.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Shell redirection and binary-safe pipes preserve the pack; text-processing filters can change bytes and expose data. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the standard input must remain binary-safe example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

cat fixture.pack | GIT_DIR=receiver.git git unpack-objects -n

Expected result and reasoning. This binary-safe pipeline should behave like input redirection for the same file. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Piping through sed, command substitution or a text logger can corrupt binary input. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Does every pipeline stage promise byte-for-byte output?”

• Evidence to collect: input/output checksum where applicable
• Variable to hold constant: the surrounding setup, so the comparison isolates standard input must remain binary-safe.
• Variable to change: insert a text transform only in a disposable demonstration
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For standard input must remain binary-safe, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an empty receiving repository. Apply standard input must remain binary-safe in an empty receiving repository. The central question is whether the same rule still governs after the context changes. The pack stream must pass through tools that preserve bytes exactly. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Avoid text decoding, newline conversion or logging the raw stream.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a CI quarantine directory. Apply standard input must remain binary-safe in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. The pack stream must pass through tools that preserve bytes exactly. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Avoid text decoding, newline conversion or logging the raw stream.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a SHA-256 test repository. Apply standard input must remain binary-safe in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. The pack stream must pass through tools that preserve bytes exactly. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Avoid text decoding, newline conversion or logging the raw stream.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a scripted stdin pipeline. Apply standard input must remain binary-safe in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. The pack stream must pass through tools that preserve bytes exactly. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Avoid text decoding, newline conversion or logging the raw stream.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Explain why command substitution is unsuitable for a pack. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Shell variables and text substitution are not designed to preserve arbitrary binary NUL bytes. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Teach the data type of the stream before shell convenience. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain standard input must remain binary-safe, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Object format compatibility · Full contents · Next: Cleanup and repacking after recovery →

CHAPTER 19 OF 20 · Back to contents

19. Cleanup and repacking after recovery

The short answer: Loose recovery objects may later be organised by normal repository maintenance once verification and refs are settled. The governing rule is: Do not run cleanup until the recovery record and required objects are secure.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Commands such as repack and prune change storage or remove unreachable objects; their timing matters after unpacking into a ref-less receiver. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the cleanup and repacking after recovery example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git count-objects -v
# create verified refs before considering maintenance

Expected result and reasoning. The count shows loose and packed storage. No cleanup is performed by the observation command. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Immediately pruning dangling recovered objects can erase the very material being investigated. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which recovered objects are reachable from preserved refs or otherwise recorded?”

• Evidence to collect: refs, OID manifest and backups
• Variable to hold constant: the surrounding setup, so the comparison isolates cleanup and repacking after recovery.
• Variable to change: create a protective ref in the disposable receiver
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For cleanup and repacking after recovery, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a damaged transfer copy. Apply cleanup and repacking after recovery in a damaged transfer copy. The central question is whether the same rule still governs after the context changes. Loose recovery objects may later be organised by normal repository maintenance once verification and refs are settled. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not run cleanup until the recovery record and required objects are secure.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a backup pack inspection. Apply cleanup and repacking after recovery in a backup pack inspection. The central question is whether the same rule still governs after the context changes. Loose recovery objects may later be organised by normal repository maintenance once verification and refs are settled. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not run cleanup until the recovery record and required objects are secure.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a forensic recovery exercise. Apply cleanup and repacking after recovery in a forensic recovery exercise. The central question is whether the same rule still governs after the context changes. Loose recovery objects may later be organised by normal repository maintenance once verification and refs are settled. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not run cleanup until the recovery record and required objects are secure.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a disposable source repository. Apply cleanup and repacking after recovery in a disposable source repository. The central question is whether the same rule still governs after the context changes. Loose recovery objects may later be organised by normal repository maintenance once verification and refs are settled. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not run cleanup until the recovery record and required objects are secure.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Write the order for verification, ref creation, backup and optional maintenance. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Verify first, record OIDs, create appropriate refs or copies, back up, then consider maintenance according to the recovery goal. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Cleanup is a decision, not the automatic last line of every tutorial. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain cleanup and repacking after recovery, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Standard input must remain binary-safe · Full contents · Next: Choosing unpack-objects for the right job →

CHAPTER 20 OF 20 · Back to contents

20. Choosing unpack-objects for the right job

The short answer: Use unpack-objects when a pack stream must be examined or expanded into missing loose objects in an explicit target repository. The governing rule is: Prefer other plumbing when the desired result is an indexed pack, simple inspection or routine network transport.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The choice should account for existing-object skipping, input trust, storage form, integrity checks and recovery goals. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the choosing unpack-objects for the right job example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

GIT_DIR=receiver.git git unpack-objects --strict --max-input-size="$limit" < fixture.pack

Expected result and reasoning. This combines explicit target, validation and a policy limit; it still requires post-write object and fsck verification. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. A command with more flags is not automatically safer if the repository, input and recovery objective are unclear. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Why is loose expansion required here?”

• Evidence to collect: written decision, target identity and verification plan
• Variable to hold constant: the surrounding setup, so the comparison isolates choosing unpack-objects for the right job.
• Variable to change: replace the goal with normal packed installation
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For choosing unpack-objects for the right job, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a CI quarantine directory. Apply choosing unpack-objects for the right job in a CI quarantine directory. The central question is whether the same rule still governs after the context changes. Use unpack-objects when a pack stream must be examined or expanded into missing loose objects in an explicit target repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Prefer other plumbing when the desired result is an indexed pack, simple inspection or routine network transport.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a SHA-256 test repository. Apply choosing unpack-objects for the right job in a SHA-256 test repository. The central question is whether the same rule still governs after the context changes. Use unpack-objects when a pack stream must be examined or expanded into missing loose objects in an explicit target repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Prefer other plumbing when the desired result is an indexed pack, simple inspection or routine network transport.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a scripted stdin pipeline. Apply choosing unpack-objects for the right job in a scripted stdin pipeline. The central question is whether the same rule still governs after the context changes. Use unpack-objects when a pack stream must be examined or expanded into missing loose objects in an explicit target repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Prefer other plumbing when the desired result is an indexed pack, simple inspection or routine network transport.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an empty receiving repository. Apply choosing unpack-objects for the right job in an empty receiving repository. The central question is whether the same rule still governs after the context changes. Use unpack-objects when a pack stream must be examined or expanded into missing loose objects in an explicit target repository. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Prefer other plumbing when the desired result is an indexed pack, simple inspection or routine network transport.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Decide among unpack-objects, index-pack and cat-file for three scenarios. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Use unpack for controlled loose expansion, index-pack for installing/verifying packed storage, and cat-file for inspecting objects already present. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask for the rejected alternatives as part of the answer. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain choosing unpack-objects for the right job, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Cleanup and repacking after recovery · Full contents · Parent guide →

Parent guide: what mastery looks like

A learner has not mastered Git unpack-objects merely because one polished example runs. Look for four behaviours: they can state the rule in plain language; predict before executing; isolate one changed condition; and explain why a transfer case is the same problem or a different one. Those behaviours make progress visible without requiring a parent to become a specialist.

Use a ten-minute check-in. Ask the learner to choose one chapter, reconstruct its example from memory, and narrate the causal chain. Then change one input. If the learner can update the prediction and justify the change, stop. More repetitions are not automatically better. Save the two-case pair and return to it after a few days.

If every answer is hesitant, reduce the scope. Return to the earliest chapter whose rule cannot be stated accurately. If explanations are fluent but real tasks still fail, move to a capstone because the missing skill is likely transfer or diagnosis. If frustration rises, separate typing errors from conceptual errors and solve only one category in that session.

Capstone practice with explained routes

Capstone 1: Rebuild the smallest trustworthy fixture

Scenario. Create a disposable Git fixture that demonstrates pack-stream recovery without unrelated project code.

Route. Record environment, input, prediction and output. Keep one nearby contrast. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The fixture is successful when another learner can reproduce the observation and explain the rule that separates the two cases. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 2: Diagnose a believable wrong explanation

Scenario. A learner has the correct output but explains it using the wrong mechanism.

Route. Change the one condition that the wrong explanation says should matter, while holding the real governing condition constant. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. If the prediction based on the wrong mechanism fails and the rule-based prediction holds, the contrast exposes the misconception. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 3: Handle an environment boundary

Scenario. Two machines or runtimes produce different observations.

Route. Capture versions, platform or browser, exact input and relevant state before comparing. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A difference is not automatically an error. Use the primary source to identify versioned or environmental conditions, then retest. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 4: Design a parent check-in

Scenario. A parent has ten minutes and no specialist background.

Route. Ask for one rule, one prediction, one run and one changed condition. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The learner demonstrates mastery by explaining the causal chain and revising from evidence, not by performing a long polished demo. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 5: Transfer into a larger project

Scenario. The isolated fixture works but the school or home project does not.

Route. Preserve the fixture, then compare project inputs and state one dependency at a time. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The first differing dependency that changes the outcome becomes the next diagnostic focus; the verified rule remains the baseline. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 6: Write a regression check

Scenario. The behaviour must remain understood after a future update.

Route. Save the smallest positive case, the near miss and the version metadata. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A useful regression check fails for a meaningful reason, reports the changed observation and points back to the governing rule. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 7: Explain a limitation honestly

Scenario. The chosen API or feature does not cover an important edge case.

Route. Name the limitation, show what evidence the tool does provide and identify a more authoritative route. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The final advice is bounded: it neither discards the useful tool nor stretches it into a guarantee it cannot make. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 8: Choose the right tool

Scenario. Several related methods or commands could appear to solve the same task.

Route. Define desired output, evaluation timing, platform boundary and acceptable failure modes. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Select the tool whose contract matches those needs and state why at least one tempting alternative was rejected. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Frequently asked questions

Is Git unpack-objects mainly a syntax topic?

No. Syntax is only the visible handle. The durable skill is deciding what the operation means, predicting its boundary conditions, and collecting evidence that distinguishes one explanation from another.

How long should one practice session be?

A focused ten-to-twenty-minute session is enough for one rule, one worked example and one contrast. Stop when the learner can explain the causal chain; save the fixture for later retrieval rather than adding tired repetitions.

Should a learner memorise every edge case?

Memorise the central rule and know where to consult the primary reference. Edge cases should be organised by cause—platform, input type, evaluation order, document tree or repository state—rather than stored as an unconnected list.

What should a parent ask if they do not code?

Ask for a prediction, the rule behind it, the observation that would disprove it, and one changed case. Those questions reveal understanding without requiring the parent to know the final technical answer in advance.

When is copying an example acceptable?

Copying is useful for establishing a trusted baseline. It becomes learning only after the student predicts the result, reconstructs the example, changes one condition and explains the changed outcome.

How can we tell a typing error from a conceptual error?

Run a known-good minimal fixture first. If that fixture fails, inspect setup and transcription. If it passes but the learner predicts the wrong outcome for a controlled variation, the misconception is conceptual.

Should practice happen in a large school project?

Not initially. Large projects contain too many moving parts. Begin in a disposable directory, tiny script or isolated HTML file, then transfer the verified rule into the larger task.

What belongs in revision notes?

Keep the rule in one sentence, a smallest successful example, a near miss, the observed output, the environment version and one diagnostic question. This compact record is more reusable than a page of copied prose.

What if different computers give different results?

Treat the difference as evidence. Record operating system, runtime or browser version, filesystem or repository state, and exact input. Then consult the versioned primary source before deciding that either result is wrong.

When should the learner move to a new topic?

Move on when they can explain the rule, predict two contrasting cases, diagnose a deliberately broken example and transfer the idea to a fresh context without step-by-step prompting.

References and verification notes

Primary technical source: Official git-unpack-objects manual. The manual documents stdin pack input, loose-object output, existing-object skipping, the same-repository no-op case, and -n, -q, -r, –strict and –max-input-size.

The worked examples were checked with Git 2.51.1 with disposable source and bare receiving repositories, generated pack streams, dry-run/real-unpack comparisons, object checks and fsck. The checks confirm the specific examples in this guide; they do not promise identical behaviour on an older version, a different operating system, a different browser implementation, or a repository with different state. Keep the version and environment with the saved fixture.

Last reviewed: 17 October 2026. This article is educational guidance for families and learners. It does not advertise a physical Punggol outlet or make admissions, affiliation, score or outcome guarantees.