Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 4 additions & 12 deletions episodes/04-changes.md
Original file line number Diff line number Diff line change
Expand Up @@ -286,8 +286,6 @@ but we haven't told Git we will want to save those changes
nor have we saved them (which we do with `git commit`).
So let's do that now. It is good practice to always review
our changes before saving them. We do this using `git diff`.
This shows us the differences between the current state
of the file and the most recently saved version:

```bash
$ git diff
Expand Down Expand Up @@ -447,12 +445,9 @@ $ git add guacamole.md
$ git diff
```

There is no output:
as far as Git can tell,
there's no difference between what it's been asked to save permanently
and what's currently in the directory.
However,
if we do this:
There is no output. Without any arguments, `git diff` compares the working directory and the staging area. After `git add`, the two versions are identical and there is nothing to show.

However, if we do this:

```bash
$ git diff --staged
Expand All @@ -473,10 +468,7 @@ index 315bf3a..b36abfd 100644
## Instructions
```

it shows us the difference between
the last committed change
and what's in the staging area.
Let's save our changes:
we can see that by adding the `--staged` argument to the command we are now comparing what’s in the staged area to the last committed change.

```bash
$ git commit -m "Modify guacamole to the traditional recipe"
Expand Down
14 changes: 8 additions & 6 deletions episodes/05-history.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,12 +22,12 @@ exercises: 0
::::::::::::::::::::::::::::::::::::::::::::::::::

As we saw in the previous episode, we can refer to commits by their
identifiers. You can refer to the *most recent commit* of the working
directory by using the identifier `HEAD`.
identifiers. Git also provides a special identifier called `HEAD`, which refers to the **most recent commit**.

We've been adding small changes at a time to `guacamole.md`, so it's easy to track our
progress by looking, so let's do that using our `HEAD`s. Before we start,
let's make a change to `guacamole.md`, adding yet another line.
We can use `HEAD` together with commands we already know to examine our project’s history.

Before we start, let's make a change to `guacamole.md` so we have something
to compare. We won’t save this change yet.

```bash
$ nano guacamole.md
Expand Down Expand Up @@ -62,7 +62,9 @@ index b36abfd..0848c8d 100644
+An ill-considered change
```

Note that `HEAD` is the default option for `git diff`, so omitting it will not change the command's output at all (give it a try). However, the real power of `git diff` lies in its ability to compare with previous commits. For example, by adding `~1` (where "~" is "tilde", pronounced [**til**\-d*uh*]), we can look at the commit before `HEAD`.
Here we have the difference between the file in our working directory and the most recently committed version.

We can also refer to earlier commits relative to `HEAD`. For example, by adding `~1` (where "~" is "tilde", pronounced [**til**\-d*uh*]), we can look at the commit before `HEAD`.

```bash
$ git diff HEAD~1 guacamole.md
Expand Down
Loading