WEBVTT

1
00:00:00.000 --> 00:00:03.611
A diff is one of the most useful views
you will use with a coding assistant.

2
00:00:03.936 --> 00:00:07.872
It lets you inspect what changed instead
of relying on a description of the change.

3
00:00:08.475 --> 00:00:10.623
In this lesson we will
make one small README

4
00:00:10.646 --> 00:00:14.234
edit and explain every part of the
comparison before staging or committing

5
00:00:14.280 --> 00:00:17.774
it. The result should be understandable
without reading an old chat.

6
00:00:18.471 --> 00:00:22.581
Start from the CP01 practice folder
with its reviewed baseline commit.

7
00:00:22.964 --> 00:00:25.216
The written chapter
explains how to initialize

8
00:00:25.251 --> 00:00:28.119
that source-only folder and
record the initial files.

9
00:00:28.630 --> 00:00:33.471
Confirm your current location and run Git
status. We want a known starting state.

10
00:00:33.680 --> 00:00:38.405
If unrelated edits already exist, preserve
and account for them rather than quietly

11
00:00:38.463 --> 00:00:42.933
treating them as part of this exercise.
The working tree is the content you edit.

12
00:00:43.107 --> 00:00:46.381
The staging area is the content
selected for the next commit.

13
00:00:46.590 --> 00:00:49.353
The commit records a
selected snapshot in history.

14
00:00:49.562 --> 00:00:52.279
These three places are shown
in the conceptual figure.

15
00:00:52.557 --> 00:00:55.216
Saving in the editor
changes the working file.

16
00:00:55.460 --> 00:00:58.699
It does not automatically stage
the change or create a commit.

17
00:00:59.024 --> 00:01:03.471
Open the README and locate the
exact line, Report label: synthetic.

18
00:01:03.796 --> 00:01:06.304
Change it to Report
label: synthetic input.

19
00:01:06.512 --> 00:01:09.612
This is the designated
human-facing label exercise.

20
00:01:09.856 --> 00:01:12.433
We are not renaming a
JSON field or changing

21
00:01:12.480 --> 00:01:15.336
a serial protocol. A small
wording improvement is enough

22
00:01:15.371 --> 00:01:19.202
to learn the Git mechanics while keeping
its purpose visible. Save the file.

23
00:01:19.446 --> 00:01:24.357
Now open the Source Control view in Visual
Studio Code and select the changed README.

24
00:01:24.601 --> 00:01:27.689
The comparison shows the
previous content and new content.

25
00:01:27.933 --> 00:01:31.915
Depending on your settings, the editor
may place them side by side or inline.

26
00:01:32.240 --> 00:01:35.282
The layout can vary, but the
underlying question is the same:

27
00:01:35.560 --> 00:01:38.440
what content differs between
the two selected states?

28
00:01:38.950 --> 00:01:41.969
Look at the removed line and
the added line. The minus marker

29
00:01:42.016 --> 00:01:45.324
identifies the previous wording.
The plus marker identifies the new

30
00:01:45.348 --> 00:01:47.936
wording. Those markers are
part of the diff display;

31
00:01:48.110 --> 00:01:52.243
they are not characters you paste into the
README. The surrounding unchanged lines

32
00:01:52.301 --> 00:01:56.597
provide context so you can locate the edit
in the document. Explain the change aloud.

33
00:01:56.922 --> 00:01:58.826
The file is README dot md.

34
00:01:59.105 --> 00:02:02.982
The previous label was synthetic.
The new label is synthetic input.

35
00:02:03.191 --> 00:02:06.825
The purpose is to make the origin of
the demonstration clearer to a reader.

36
00:02:07.150 --> 00:02:11.550
Firmware, numeric values, and policy have
not been changed by this intended edit.

37
00:02:11.876 --> 00:02:15.661
We can make that last statement because
we inspect the changed-file list, not

38
00:02:15.707 --> 00:02:19.527
because we hope it is true. Use the
terminal for the equivalent inspection.

39
00:02:20.131 --> 00:02:23.103
Run Git status, then Git
diff with the README path.

40
00:02:23.428 --> 00:02:25.912
The ordinary diff compares
working content against

41
00:02:25.936 --> 00:02:29.558
staging. Because we have not staged
the edit, it should appear here.

42
00:02:30.069 --> 00:02:32.275
Run Git diff with the
cached option as well.

43
00:02:32.600 --> 00:02:36.327
If staging still matches the baseline
commit, that comparison should be empty.

44
00:02:36.838 --> 00:02:39.984
An empty cached diff does not
mean there are no working changes.

45
00:02:40.263 --> 00:02:44.268
It means there is no difference in that
particular comparison. This distinction

46
00:02:44.315 --> 00:02:47.078
becomes important when you
edit a file after staging it.

47
00:02:47.519 --> 00:02:50.700
One file can then have a selected
version in the index and a newer

48
00:02:50.758 --> 00:02:54.833
version in the working tree. We will
demonstrate that state in the next lesson.

49
00:02:55.158 --> 00:02:57.736
Read the file header as
well as the colored lines.

50
00:02:58.119 --> 00:03:01.974
If the path is not the README you
intended, investigate the project root.

51
00:03:02.299 --> 00:03:06.467
If several files appear, ask which
part of the task justifies each one.

52
00:03:06.792 --> 00:03:11.157
A one-line policy edit can matter more
than many lines of harmless documentation,

53
00:03:11.308 --> 00:03:13.746
so changed-line count
alone is a poor measure

54
00:03:13.781 --> 00:03:17.705
of consequence. Sometimes a diff shows
the whole file replaced even though

55
00:03:17.728 --> 00:03:22.059
you changed one sentence. That can happen
when formatting or line endings changed

56
00:03:22.094 --> 00:03:26.006
across the file. Do not simply accept
the large comparison because the visible

57
00:03:26.041 --> 00:03:27.074
sentence looks right.

58
00:03:27.678 --> 00:03:30.383
Identify the cause,
preserve useful content,

59
00:03:30.406 --> 00:03:32.658
and make the intended
small edit reviewable.

60
00:03:33.471 --> 00:03:37.302
A clear diff is an aid to reasoning,
not just an aesthetic preference.

61
00:03:37.999 --> 00:03:41.366
Now imagine an assistant made the same
README improvement and also adjusted

62
00:03:41.389 --> 00:03:43.386
a warning threshold. The added word might

63
00:03:43.409 --> 00:03:47.020
be correct, but the threshold change
belongs to a different decision. The diff

64
00:03:47.066 --> 00:03:49.319
helps you separate those
ideas. You can accept

65
00:03:49.342 --> 00:03:52.673
the useful documentation while
rejecting the unrelated behavior change.

66
00:03:53.370 --> 00:03:56.168
Later we will practice that
review explicitly on a branch.

67
00:03:56.551 --> 00:03:59.767
Verification should match the
claim. For this README line,

68
00:03:59.941 --> 00:04:03.413
inspect the wording and confirm it
still identifies synthetic input.

69
00:04:03.854 --> 00:04:07.337
No new unit test is necessary just
to prove that a word was added.

70
00:04:07.848 --> 00:04:11.029
If source or build commands changed,
run the appropriate project

71
00:04:11.052 --> 00:04:15.174
checks. Do not imply a program was tested
merely because the editor shows a clean

72
00:04:15.232 --> 00:04:17.891
comparison or the assistant
says the edit is complete.

73
00:04:18.216 --> 00:04:22.384
For your exercise, submit the actual
diff and a four-sentence explanation.

74
00:04:22.825 --> 00:04:24.729
Name the file, old content,

75
00:04:24.880 --> 00:04:28.108
new content and purpose, and
the scope outside the change.

76
00:04:28.491 --> 00:04:31.695
Confirm that the cached comparison
is empty before staging.

77
00:04:32.020 --> 00:04:35.294
If your state differs, explain
it and correct the starting point

78
00:04:35.538 --> 00:04:38.568
rather than copying the expected
result into your record.

79
00:04:39.172 --> 00:04:41.924
Read the diff in the direction
of the proposed change.

80
00:04:42.249 --> 00:04:45.163
Ask what a reader would see
before and after applying it.

81
00:04:45.674 --> 00:04:48.146
Then check whether the brief
wanted that difference.

82
00:04:48.750 --> 00:04:51.234
This habit avoids a common review mistake:

83
00:04:51.513 --> 00:04:54.938
approving text because each line
looks reasonable in isolation,

84
00:04:55.112 --> 00:04:58.328
without noticing that the change
removes an important condition.

85
00:04:58.932 --> 00:05:03.344
Here the extra word clarifies origin.
In a later requirement edit,

86
00:05:03.460 --> 00:05:07.593
a removed word such as invalid could
alter the meaning much more substantially.

87
00:05:07.918 --> 00:05:12.028
Keep the file uncommitted at the end of
this exercise so the next lesson can show

88
00:05:12.109 --> 00:05:16.184
staging and committing the same change.
You are ready to advance when you can say

89
00:05:16.231 --> 00:05:20.190
exactly what the diff compares and why
the changed line belongs in the task.

90
00:05:20.631 --> 00:05:22.976
That small habit scales
from a README sentence

91
00:05:23.127 --> 00:05:25.821
to a policy correction that
affects a boundary case.