Checkpoint Lab — Commits, Diffs, History Inspection, Revision Ranges, and Message Discipline

1. Checkpoint scenario — turn a messy local feature history into reviewable operational history

You will create a feature branch with one good commit and one intentionally bad unpublished commit that mixes documentation and runtime configuration. You will inspect the damage, split the bad commit using a controlled local history rewrite, improve one unpublished message with --amend, and produce an exact review report.

2. Predictions before changing history

1. If a mixed commit is replaced by two commits, will its original commit OID remain at the feature tip?
2. Will git reset HEAD^ (default mixed mode) preserve the mixed commit's file changes in the working tree while moving the branch back one commit?
3. If you amend only a commit message, will the commit OID change even though the tree stays the same?
4. Will trunk..feature/retry list exactly the feature commits not reachable from trunk?

3. Setup and preflight

Git Bash / Bash / zsh

mkdir git-history-checkpoint
cd git-history-checkpoint
git init -b trunk
git config user.name "History Checkpoint"
git config user.email "history-checkpoint@example.invalid"
printf "retries=2
timeout=10
" > app.conf
printf "# Service Runbook

Baseline deployment procedure.
" > RUNBOOK.md
git add app.conf RUNBOOK.md
git commit -m "Create service retry baseline"
git status --short --branch
git log --oneline --decorate

PowerShell alternative

New-Item -ItemType Directory git-history-checkpoint | Out-Null
Set-Location git-history-checkpoint
git init -b trunk
git config user.name "History Checkpoint"
git config user.email "history-checkpoint@example.invalid"
@('retries=2','timeout=10') | Set-Content app.conf
@('# Service Runbook','','Baseline deployment procedure.') | Set-Content RUNBOOK.md
git add app.conf RUNBOOK.md
git commit -m "Create service retry baseline"
git status --short --branch
git log --oneline --decorate

Record BASE=$(git rev-parse HEAD) (PowerShell: $BASE = git rev-parse HEAD). There is no remote, so all feature history created next is unpublished.

4. Create one coherent feature commit

git switch -c feature/retry
# Edit app.conf so retries=3, leaving timeout unchanged.
git diff -- app.conf
git add -- app.conf
git diff --staged -- app.conf
git commit -m "Retry transient uploads three times"
git show --stat --oneline HEAD

The subject says what behavior changes. The reason is inferable from “transient uploads” and is still concise enough for release/review views.

5. Intentionally create a poor mixed commit boundary

Git Bash / Bash / zsh

printf "retries=3
timeout=30
" > app.conf
printf "# Service Runbook

Baseline deployment procedure.

Monitor retry exhaustion alerts.
" > RUNBOOK.md
git status --short
git diff
git add app.conf RUNBOOK.md
git diff --staged
git commit -m "update files"
BAD=$(git rev-parse HEAD)
git show --stat --oneline HEAD

This commit is valid but poor: runtime timeout policy and operational documentation are different reasons, and the message narrates nothing useful.

6. Preserve evidence before splitting the unpublished commit

git status --short --branch
git log --graph --decorate --oneline -4
git show --stat HEAD
git show HEAD -- app.conf
git show HEAD -- RUNBOOK.md
git rev-parse HEAD
git rev-parse HEAD^

Write down the bad commit OID and its parent. This makes the rewrite observable rather than magical.

7. Split only the unpublished local commit

git reset HEAD^
git status --short
git diff
git diff --staged

Expected: the feature branch points back to the good retry commit; both app.conf and RUNBOOK.md are modified in the working tree; the staged diff is empty.

8. Commit the runtime policy as one reason

git add -- app.conf
git diff --staged -- app.conf
git diff -- RUNBOOK.md
git commit -m "Increase upload timeout for slow archives" -m "Large archive uploads can exceed the previous 10-second window even when the service is healthy. Keep retry count unchanged and extend only the per-attempt timeout."
RUNTIME=$(git rev-parse HEAD)
git show --format=fuller --stat HEAD

The body explains why the timeout changes and distinguishes it from the retry-count behavior introduced by the previous commit.

9. Commit the runbook update separately

git status --short
git add -- RUNBOOK.md
git diff --staged -- RUNBOOK.md
git commit -m "Document retry exhaustion monitoring"
DOCS=$(git rev-parse HEAD)
git status --short

The working tree should now be clean. The original BAD commit is no longer the feature tip; it has been replaced by two coherent commits.

10. Improve an unpublished message with --amend

Suppose the docs subject should explicitly state why the monitoring step matters. Because this is still a local disposable branch with no remote, amend it:

OLD_DOCS=$(git rev-parse HEAD)
git commit --amend -m "Document retry exhaustion alert response" -m "Operators need an explicit check after retry exhaustion so slow-upload incidents are distinguished from permanent failures."
NEW_DOCS=$(git rev-parse HEAD)
git rev-parse HEAD
git show --no-patch --format=fuller HEAD

Predict and verify that OLD_DOCS and NEW_DOCS differ even though the tree content did not change.

11. Answer concrete review questions with exact commands

# 1. What commits would feature/retry add to trunk?
git log --oneline trunk..feature/retry

# 2. What exact content differs at the feature tip?
git diff trunk feature/retry

# 3. What changed only on the feature side since divergence?
git diff trunk...feature/retry

# 4. Which commit changed app.conf and why?
git log --oneline -- app.conf
git show --format=fuller -- app.conf

# 5. Show machine-oriented feature commit OIDs.
git rev-list trunk..feature/retry

# 6. Compact graph for a human reviewer.
git log --graph --decorate --oneline --all

12. Produce a compact reproducible history report

git status --porcelain=v2 --branch
git rev-parse --verify trunk
git rev-parse --verify feature/retry
git rev-list --count trunk..feature/retry
git log trunk..feature/retry --date=iso-strict --pretty=format:'%H%x09%aI%x09%an%x09%s'
git diff --stat trunk...feature/retry
git diff --check trunk...feature/retry

The full OID report is suitable for provenance. The stat summarizes feature-side snapshot change from the merge base. diff --check can flag whitespace errors in the comparison; a clean result produces no output.

13. What made the original boundary bad?

14. Verification checklist

• The repository has no remote; rewritten commits were unpublished.
• The baseline remains reachable from trunk.
• feature/retry contains one retry-count commit, one timeout-policy commit, and one runbook commit.
• The bad mixed commit OID is no longer the feature tip.
• The amended docs commit has a different OID from its pre-amend version.
• git status --short is clean.
• git diff --check trunk...feature/retry reports no whitespace errors.
• The history report uses full OIDs for machine provenance and human-readable messages for review.

15. Cleanup

Git Bash / Bash / zsh

git status --short --branch
cd ..
pwd
rm -rf git-history-checkpoint

PowerShell

git status --short --branch
Set-Location ..
Get-Location
Remove-Item -Recurse -Force git-history-checkpoint

16. Knowledge check

17. What Chapter 05 adds to a production Git operating model

You can now create commits from a deliberately reviewed index, interrogate history as graph/set/snapshot data, write messages that preserve operational intent, and distinguish safe local cleanup from prohibited published-history rewriting. That makes the next chapter's branching and merge decisions observable rather than ceremonial.

18. Chapter checkpoint summary

Reviewable history comes from coherent snapshots, explicit parent/range reasoning, reproducible diff commands, and messages that explain intent. Git gives you precise graph and comparison primitives; discipline determines whether the resulting history becomes useful operational data.

Authoritative references

• git-commit
• git-log
• git-rev-list
• git-diff
• gitrevisions