Different Royal Breakfasts (Meet Git #7)

How to check what has been committed and when

Krystian Szpiczakowski

Published in

CodeX

5 min readDec 17, 2022

Introduction

A change is something that drives the progress of everything. Without changes, we would stick to a plain sandwich, but now we’ve got a quite decent breakfast.

Because changes are so important, today we’re going to take a look at how The Royal Breakfast was evolving in time. To achieve this, we’ll use git log, git diffand git show.

Show what has been committed and when

Check details of the particular commit

To recall, we’ve got three commits in our history, and say, we would like to check details of the first commit (1033ca3).

To get more information about that commit, type git log 1033ca3, or even shorter git log 1033, provided you can uniquely identify the commit. If you want to display all commits, just use git log, without specifying the commit’s checksum.

Display a single entry in git history by using git log

Display all commits from history by using git log

As you can see, this doesn’t present the exact changes in the recipe, though. To find out what changes have been introduced by commit 1033ca3, use git show 1033ca3.

Apart from metadata, such as an author and commit date, you can see the all changes made within the royal_breakfast.txt recipe.

In general, git show <commit_sha> gives you details on what has been changed in a particular commit, compared to its parent. The first commit in Git repository is a bit special, though, because it has no parent commit!

How to know which commit is a parent of another? To get a nice view of history in your repository, and to see relationships between commits, I encourage you to create the git lga alias in Git. I have described the required steps here¹.

Display the exact changes within the file by using git show

With git lga, you can easily figure out what history looks like

Check differences between two versions of the breakfast

If you would like to know, what differences are between a broader set of commits, use git diff from_revision..to_revision, for example, git diff 1033..cab78. In this particular example, Git will display changes introduced by c033 and cab78.

git diff lets you inspect a broader set of commits at once

Show differences before you commit next changes

The well known git diff command lets you not only review the history of already committed snapshots, but also helps you find out

what has been changed since the last commit (e.g. if you modified the recipe with your favorite text editor)
what is to be committed (when you modified the recipe, and you’ve already staged changes, but haven’t committed them yet)

What has been changed since the last commit?

To figure it out, you can use two commands:

git status tells you which files were modified
git diff provides more detailed information and shows what exactly has been changed within tracked files

There is one important note regarding using git diff. If you have a long line of text, and you’re changing only a few words within it, git diff may produce quite confusing output, like in the screenshot below.

At first glance, it looks like I changed a lot within royal_breakfast.txt. In reality, I have changed only a single word. The output looks as it looks because by default git diff detects whole lines that are modified. To get a better view of what I really changed, I used git diff --word-diff, which highlights only words that were changed. The output of this command has been shown in the next screenshot.

git status displays names of modified files

git diff simply displays whole lines that have been changed

Use git diff along with the “word-diff” flag in order to highlight only modified words in a single line.

What changes are going to be committed?

If you staged (prepared) changes for the next commit, git status should produce output as shown below.

What’s interesting, git diff doesn’t show any changes. It’s because git diff compares the working directory that is not staged. The royal_breakfast.txt has been already staged, so use git diff --cached instead.

git diff doesn’t present changes if they are staged

Use git diff along with the “cached” flag to show staged changes

Use the “word-diff” flag to display only words that have been changed

Under certain circumstances, Git displays information that may look even more confusing. Namely, if you type git status, Git can tell you that the same file is

modified but not staged (marked in red)
modified and staged (marked in green)

A file can be staged and not staged at the same time

This simply means, that you had modified a file and staged it. Later on, you decided to introduce another changes in the same file, without adding the file to the staging area again.

If I type git diff --word-diff, the output says I added “chop chop” in the text, and this change is not staged, because I used the command without the “cached” flag.

On the other hand, if I type git diff --cached --word-diff, the produced output says that the word “Finely” has been replaced with “Roughly”.

If I committed the file as it is, my new commit would only contain the change from “Finely” to “Roughly”. Let’s see if my assumption is correct, then.