WEBVTT

1
00:00:00.000 --> 00:00:04.168
We have verified the private destination.
Now we will transfer the local history

2
00:00:04.226 --> 00:00:08.081
and reproduce the project from a second
checkout. This is more than a backup

3
00:00:08.139 --> 00:00:12.342
exercise. It tests whether the files and
instructions you preserved are enough

4
00:00:12.376 --> 00:00:16.660
to repeat the baseline without relying on
leftovers in the original working folder.

5
00:00:17.264 --> 00:00:21.153
Start in the reviewed local
practice repository. Check status,

6
00:00:21.270 --> 00:00:24.753
branch, and remote again if the state
changed since the previous lesson.

7
00:00:25.194 --> 00:00:28.572
Run the push command with the
upstream option for origin and main.

8
00:00:28.955 --> 00:00:30.801
Inspect the actual result.

9
00:00:31.243 --> 00:00:34.911
A successful-looking browser page is
not a substitute for the terminal's

10
00:00:34.958 --> 00:00:38.359
transport result, and an error
should remain visible in your record.

11
00:00:38.801 --> 00:00:41.216
Push sends local commits
and requests an update

12
00:00:41.239 --> 00:00:45.314
on the remote. The upstream option records
a tracking relationship for the branch.

13
00:00:45.697 --> 00:00:48.901
That relationship makes later
status information more useful,

14
00:00:49.110 --> 00:00:52.826
but it does not prove every future
synchronization will be conflict-free.

15
00:00:53.151 --> 00:00:57.586
Other work can arrive on the remote after
this operation. Fetch has a different job.

16
00:00:57.795 --> 00:01:00.720
It retrieves remote objects and
updates your local knowledge

17
00:01:00.755 --> 00:01:04.482
of remote references without integrating
them into the current working branch.

18
00:01:04.992 --> 00:01:08.185
This makes it useful before
deciding how to incorporate changes.

19
00:01:08.510 --> 00:01:13.386
Pull includes integration. In simple cases
where the branch should only advance,

20
00:01:13.503 --> 00:01:17.682
the fast-forward-only option stops
instead of creating an unexpected merge.

21
00:01:18.495 --> 00:01:22.198
After the push, open the hosted
repository and inspect the README

22
00:01:22.233 --> 00:01:25.902
and recent history. Compare the latest
commit identifier with the local

23
00:01:25.983 --> 00:01:28.189
rev-parse result shown
in the written lesson.

24
00:01:28.572 --> 00:01:31.835
Make sure the browser is on the
intended owner and repository.

25
00:01:32.276 --> 00:01:35.340
This cross-check catches a
surprisingly easy mistake:

26
00:01:35.515 --> 00:01:39.567
a correct push viewed beside a
stale or unrelated repository tab.

27
00:01:39.892 --> 00:01:42.074
Now leave the original working directory.

28
00:01:42.318 --> 00:01:45.697
Open a terminal in the parent
learning folder and clone the verified

29
00:01:45.766 --> 00:01:49.412
URL into a new folder
named sensor-monitor-repro.

30
00:01:49.621 --> 00:01:53.568
If that destination already contains work,
choose another new name. Do not delete

31
00:01:53.592 --> 00:01:57.620
a useful folder simply because an example
command expects an empty destination.

32
00:01:57.945 --> 00:02:00.476
Enter the new checkout
and run Get-Location,

33
00:02:00.592 --> 00:02:02.682
Git status, and the commit inspection.

34
00:02:03.007 --> 00:02:07.233
The location should be the new folder.
The initial working tree should be clean,

35
00:02:07.349 --> 00:02:11.726
and the commit should match the intended
synchronized history. These observations

36
00:02:11.784 --> 00:02:15.837
establish where the following commands
will run and which source they will use.

37
00:02:16.347 --> 00:02:19.772
Follow only the new checkout's
README and dependency record.

38
00:02:20.283 --> 00:02:24.010
Resist the temptation to open a remembered
terminal in the original folder.

39
00:02:24.393 --> 00:02:29.374
For CP01, run the replay command wrapper
and firmware build wrapper separately.

40
00:02:29.699 --> 00:02:33.216
This checkpoint has a minimal
source-reading baseline. It does not yet

41
00:02:33.263 --> 00:02:37.640
contain the later fixture parser, policy
tests, or configurable alert behavior.

42
00:02:38.151 --> 00:02:39.439
Read the replay result.

43
00:02:39.822 --> 00:02:44.838
CP01 prints a fixed JSON sample
explicitly marked synthetic.

44
00:02:45.349 --> 00:02:49.540
That output is useful evidence that the
host baseline compiled and ran in the new

45
00:02:49.598 --> 00:02:53.290
checkout. It is not a temperature
measured by a connected sensor.

46
00:02:53.615 --> 00:02:56.668
Keep the origin label with the
saved result so that a later

47
00:02:56.738 --> 00:02:59.768
reader does not have to infer
how the input was produced.

48
00:03:00.093 --> 00:03:04.784
Read the firmware build result separately.
The target options are part of the input,

49
00:03:04.958 --> 00:03:07.466
so use the configuration
in the matching release.

50
00:03:07.791 --> 00:03:12.249
A successful cross-build establishes
compilation for that target and toolchain.

51
00:03:12.632 --> 00:03:16.103
It does not establish an upload,
electrical communication,

52
00:03:16.278 --> 00:03:18.855
sensor accuracy, or physical timing.

53
00:03:19.134 --> 00:03:22.175
Those are different observations
in optional hardware work.

54
00:03:22.501 --> 00:03:26.274
A second checkout on the same
computer has a useful limit.

55
00:03:26.599 --> 00:03:29.385
It reuses installed
tools and dependencies.

56
00:03:29.710 --> 00:03:33.031
It can reveal a missing tracked
header, an uncommitted script,

57
00:03:33.124 --> 00:03:36.734
or reliance on the original folder's
generated files. It does not

58
00:03:36.792 --> 00:03:40.438
prove that the setup instructions
work on a completely empty machine.

59
00:03:40.821 --> 00:03:45.268
Write that limitation rather than
overstating a valuable but bounded check.

60
00:03:45.651 --> 00:03:49.505
Suppose the build fails because a required
source file is missing from the clone.

61
00:03:49.831 --> 00:03:52.826
Inspect the tracked-file list
and compare with the original.

62
00:03:53.151 --> 00:03:57.447
If the file belongs in source, add it
deliberately, explain the correction,

63
00:03:57.656 --> 00:04:00.756
synchronize, and repeat the
affected check from clean source.

64
00:04:01.139 --> 00:04:05.969
The failed reproduction has identified an
actual omission; it is not wasted effort.

65
00:04:06.352 --> 00:04:09.440
Suppose instead that the
compiler is not found.

66
00:04:09.765 --> 00:04:11.925
That is a dependency or path problem.

67
00:04:12.250 --> 00:04:15.234
Follow the documented installation
and wrapper configuration.

68
00:04:15.559 --> 00:04:18.635
Do not copy an arbitrary
installed executable

69
00:04:18.844 --> 00:04:21.875
into the repository merely to
make the second folder build.

70
00:04:22.258 --> 00:04:25.416
The source history should point
to reproducible dependencies,

71
00:04:25.590 --> 00:04:28.887
while the setup record identifies
what was installed and tested.

72
00:04:29.398 --> 00:04:33.067
If a push is rejected because the
remote is ahead, preserve local work,

73
00:04:33.183 --> 00:04:36.921
fetch, and inspect the graph.
A fast-forward-only pull

74
00:04:36.979 --> 00:04:41.147
can handle a simple advance when
no unique local commits conflict.

75
00:04:41.751 --> 00:04:46.117
Divergent history needs review and
integration, which the next lessons teach.

76
00:04:46.500 --> 00:04:50.064
Force-push is not the generic answer
to a state you have not inspected.

77
00:04:50.389 --> 00:04:54.685
Your reproduction record should name
the URL without credentials, commit,

78
00:04:54.812 --> 00:04:59.874
destination folder, tool versions,
commands, exit results, and limitations.

79
00:05:00.385 --> 00:05:02.347
Keep output that actually occurred.

80
00:05:02.730 --> 00:05:06.074
Do not replace a failure with a
screenshot from the original checkout.

81
00:05:06.399 --> 00:05:10.939
A useful record lets another person
understand both the result and its scope.

82
00:05:11.322 --> 00:05:15.339
If a second checkout succeeds only
because you manually copied generated

83
00:05:15.397 --> 00:05:19.170
output from the first, record that
as a failed reproduction attempt.

84
00:05:19.983 --> 00:05:22.932
The point is to reconstruct
the executable from committed

85
00:05:23.001 --> 00:05:25.335
source and documented dependencies.

86
00:05:25.846 --> 00:05:28.749
Existing artifacts can
be useful for comparison,

87
00:05:29.074 --> 00:05:31.674
but they should not conceal
a missing build step.

88
00:05:32.116 --> 00:05:37.340
A clean reproduction may still use cached
dependency downloads; identify that reuse

89
00:05:37.410 --> 00:05:42.042
honestly while ensuring the project
itself is rebuilt in the new location.

90
00:05:42.483 --> 00:05:46.105
Complete the exercise by reproducing
the baseline from your second

91
00:05:46.163 --> 00:05:49.948
folder using the written
instructions. If a step was missing,

92
00:05:50.157 --> 00:05:53.779
correct the documentation and
rerun only the affected checks.

93
00:05:54.221 --> 00:05:58.296
You are ready to advance when the intended
history is synchronized and the second

94
00:05:58.331 --> 00:06:02.220
checkout produces its applicable
software evidence. Next we will use

95
00:06:02.255 --> 00:06:05.436
a feature branch to review an
agent change before accepting it.