Exercise 2: Read a Diff — Possible Solution
====================================================================

EXAMPLE FILE (before edit)
------------------------------
Hello, world!
This is line two.

EXAMPLE EDIT
------------------------------
Hello there, world!
This is line two.
This is a brand new line three.

STEPS
------------------------------
1. Make the edit above: change "Hello, world!" to "Hello there,
   world!", and add a new third line.
2. Save the file.
3. Open the Source Control panel (Ctrl+Shift+G). The file appears
   under "Changes" — before staging it, click directly on the
   filename (not the "+" icon) to open its diff view.
4. In the diff view:
   - The OLD version of line 1 ("Hello, world!") is shown struck
     through or highlighted in RED — a removed line.
   - The NEW version of line 1 ("Hello there, world!") is shown
     highlighted in GREEN — an added line, replacing the old one.
   - Line 2 ("This is line two.") appears with no highlight at all —
     unchanged lines are shown plainly for context, not colored.
   - The new line 3 ("This is a brand new line three.") is shown
     entirely in GREEN — a pure addition with no corresponding old
     line.

WHY THIS WORKS AS AN ANSWER
------------------------------
Clicking the filename itself (rather than the "+" stage icon) reuses
this chapter's own distinction — the diff view opens specifically from
clicking the file, which is a separate action from staging it, letting
you review a change before deciding whether to stage it at all.

The red-for-removed, green-for-added color coding reused here matches
the chapter's own description exactly. Because the edit deliberately
included one CHANGED line (which git and VS Code represent as a
removal-plus-addition pair, not an in-place edit) and one purely NEW
line, this exercise demonstrates both ways a diff can present a
change — a genuinely common source of confusion for someone expecting
a changed line to show as a single highlighted line rather than a
red/green pair.