0:00:00.240,0:00:03.070
To answer this question, let's think[br]about what commits were present on

0:00:03.070,0:00:06.210
GitHub and in your local repository[br]before and after git fetch.

0:00:07.250,0:00:08.600
When you cloned the repository,

0:00:08.600,0:00:11.900
the latest commit on it was Larry's[br]commit adding the chili recipe, so

0:00:11.900,0:00:15.330
that also became the latest[br]commit in your local repository.

0:00:15.330,0:00:17.230
Of course,[br]there were other previous commits, but

0:00:17.230,0:00:19.810
I'm leaving them out here for[br]the sake of space.

0:00:19.810,0:00:22.240
Now you made a commit[br]adding a new spice, so

0:00:22.240,0:00:25.590
that commit is also present[br]in your local repository.

0:00:25.590,0:00:27.815
And that's where your master branch is.

0:00:27.815,0:00:31.530
origin/master still points to[br]the commit that was on the remote at

0:00:31.530,0:00:33.210
the time that you cloned.

0:00:33.210,0:00:36.654
After you cloned, Sarah added[br]the no cumin commit on GitHub, but

0:00:36.654,0:00:40.280
your origin/master branch[br]won't reflect that yet.

0:00:40.280,0:00:42.960
So, this is the state[br]of master on GitHub.

0:00:42.960,0:00:43.890
Now, this was the state of

0:00:43.890,0:00:46.800
both repositories right[br]before you ran git fetch.

0:00:46.800,0:00:51.640
So, if you ran git log origin/master,[br]you should have seen that Larry's commit

0:00:51.640,0:00:55.760
adding the chili recipe was present,[br]but your commit adding a new spice and

0:00:55.760,0:01:00.490
Sarah's commit removing cumin were not[br]present on the origin/master branch.

0:01:00.490,0:01:03.865
If you run git status, you should have[br]seen that your branch was ahead of

0:01:03.865,0:01:06.390
origin/master by one commit.

0:01:06.390,0:01:10.720
This makes sense because git log and git[br]status both run without internet access.

0:01:10.720,0:01:12.940
Suppose you were somewhere[br]without internet access when you

0:01:12.940,0:01:14.340
ran these commands.

0:01:14.340,0:01:18.510
Your local git repository would have[br]no idea that the cumin commit existed.

0:01:18.510,0:01:21.220
So, of course, the cumin commit[br]wouldn't be shown when you ran git

0:01:21.220,0:01:22.505
log origin/master.

0:01:23.920,0:01:28.380
And git status wouldn't know that your[br]branches were actually out of sync.

0:01:28.380,0:01:30.660
It thinks that your[br]branch is just ahead.

0:01:30.660,0:01:34.710
Now when you run git fetch,[br]git fetches the no cumin commit and

0:01:34.710,0:01:38.370
updates the branch origin/master[br]to point to that new commit.

0:01:38.370,0:01:42.420
Your local master still points at[br]the new spice commit like it did before.

0:01:42.420,0:01:46.350
So at this point, you have a local[br]copy of the no cumin commit saved, and

0:01:46.350,0:01:48.030
you can access it via git log.

0:01:48.030,0:01:52.340
If you run git log now,[br]you'll see both the no cumin commit and

0:01:52.340,0:01:53.760
the chili commit.

0:01:53.760,0:01:56.740
You still won't see your new[br]spice commit since that's only on

0:01:56.740,0:01:58.350
your local master branch.

0:01:58.350,0:02:00.340
Now, since both origin slash master and

0:02:00.340,0:02:02.955
master have one commit that[br]is not present on the other,

0:02:02.955,0:02:07.325
git status will show that your branch[br]is out of sync with origin/master.