Give some fireworks to your cookbook (Meet Git #9)

Can Git handle MS Word/LibreOffice documents?

Photo by Ray Hennessy on Unsplash

Introduction

Previously, we were working on our first recipe in the cookbook. If you haven’t read my previous articles, I encourage you to start here¹, where we started off with a new Git repository, and we kept improving the Royal Breakfast recipe.

Up until now, we’ve been editing the recipe as a plain .txt file. Although this format is suitable if the only goal is to store text, it can’t hold information about headings, table of contents, font colors and so on.

Because we want our cookbook to have a more professional feel, the next step is to add formatting to it. How can we achieve this? Let’s move from plain text to rich text document!

Make the cookbook more appealing

Create a new MS Word document

First, let’s move the entire recipe to a newly created .docx document, and create a commit.

The recipe saved as Microsoft Word document

Stage the .docx document

Create a commit with a meaningful name

The new snapshot is available in history

Sprinkle some formatting on top of breakfast

I’ve added a title, headings, and changed font types. It’s time to create another commit that will include these changes.

Breakfast recipe includes formatting

Added commit with the formatted document

Add a picture of breakfast

It would be nice to show our readers what breakfast looks like, so they know what to expect from this recipe. Let’s add a picture, then.

Added a picture of breakfast

Another snapshot with the picture has been created

What about history?

As you can see, everything in history seems fine. Each snapshot represents a point in time, so we can easily revert the recipe if needed.

Three commits representing changes in MS Word document

Let’s compare differences between commits 2129442 and 7380968. As you can see, git diff 2129442..7380968 doesn’t say much. It’s because MS Word files are not really text documents, even if they may look so. For Git, such documents are binary files, which means there’s no way to check differences between snapshots.

Comparing binary files doesn’t say much

Even if we’re using a modified version of the command above, i.e. git diff --binary 2129442..7380968, the returned message is quite cryptic, as shown below.

Comparing commits with the “binary” flag isn’t meaningful, too

Should I store binary files in Git?

As a general rule, Git excels at storing text documents. In our case, however, the recipe stored as the .docx file, which is binary, makes Git doesn’t know how to compare differences between snapshots.

Here are pros of using binary files in Git:

• we can still use Git to store snapshots
• if you want, you can use git reset to undo changes introduced in history, but you’ll lose affected commits

There are some serious drawbacks, though:

• we can’t see the exact differences between commits
• we can’t use git revert to undo changes introduced in previous commits, because Git is unable to see the difference between snapshots
• using more advanced commands like git merge and git rebase to manipulate history is also impossible

Is there any alternative?

You may be wondering if there are any alternatives to produce documents more interesting than just plain .txt files, which are more Git-friendly than .docx at the same time. There are a few methods to achieve this goal out there, and we’ll take a closer look at one of them in the next article.

References

[1] Krystian Szpiczakowski, How to start cooking with Git (Meet Git #4) https://medium.com/codex/how-to-start-cooking-with-git-meet-git-4-a286e4e08109