Background

I had finished writing my previous post. In rake preview, I got the desired output. Then, the next step is to commit the changes and to deploy the generated contents to GitHub Pages.

Problem

A large block of red text appeared after I ran rake deploy. The commit on the master branch was unsuccessful.

$ rake deploy
(in C:/github/vincenttam.github.io)
cp -r source/fancybox/.gitattributes public/fancybox/.gitattributes
cd _deploy
Already up-to-date.
cd -
rm -rf _deploy/404.html
...
rm -rf _deploy/stylesheets
cp -r public/. _deploy
cd _deploy
fatal: CRLF would be replaced by LF in fancybox/README.md.
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
        modified:   404.html
        modified:   about/index.html
        ...

Untracked files:
        blog/2016/02/21/
        blog/2016/02/22/
        downloads/code/miktex-update2/
        images/posts/MikTeXUpdate2/
        posts/31/

no changes added to commit
Everything up-to-date
cd -
## Set the codepage to 65001 for Windows machines
## Deploying branch to Github Pages
## Pulling any updates from Github Pages

## Copying public to _deploy

## Committing: Site updated at 2016-02-22 03:37:22 UTC

## Pushing generated _deploy website

## Github Pages deploy complete

Even though the system said that the deploy was “complete”, in fact, it had never been carried out.

How can I update my blog on GitHub Pages?

Discussion

In the above error output, it took me a minute to find out at which stage the deploy had failed: the line starting with “fatal”. Therefore, I stripped off all \r from source/fancybox/README.md. I tried deploying it again, and it failed—the same “fatal” error appeared for another file. I tried committing the change for source/fancybox/README.md, but I couldn’t commit this. I tried googling “fatal crlf would be replaced by lf”, and clicked on the first search result. The answers in this Stack Overflow question suggested that the option core.autocrlf should be configured to false. To be safe, I turned on core.safecrlf.¹

When I updated Git for Windows, I chose “Checkout Windows-style, commit Unix-style line endings” (the first radio button), which the Git Setup dialog recommended.

</source>

Picture from imgur.

I love using bash utilities and (G)Vim. In Git Bash, the former gives LF line terminators, while the later gives CRLF. Therefore, I decided to set fileformat=unix in my VIMRC.² However, this doesn’t unify the EOL of files in the local repository.

As I clone Git repositories, the line terminators are automatically converted to CRLF.

Solution

Completely get rid of carriage returns \r in Git repositories!

To see how many files had CRLF line terminators, I tried using grep in Git Bash, but this answer on Stack Overflow didn’t work.

$ find source -type f -exec grep -Iq . {} \; -and -exec dos2unix {} \;
dos2unix: converting file source/404.md to Unix format...
dos2unix: converting file source/about/index.markdown to Unix format...
dos2unix: converting file source/about/mybyobuconf.markdown to Unix format...
...
dos2unix: converting file source/_posts/2016-02-22-git-for-windows-curl-with-vun
dle-1.markdown~ to Unix format...
dos2unix: converting file source/_posts/2016-02-22-testing-octopress-and-ruby-2-
dot-0-on-windows-7-3.markdown to Unix format...
dos2unix: converting file source/_posts/2016-02-22-testing-octopress-and-ruby-2-
dot-0-on-windows-7-3.markdown~ to Unix format...

For the explanation of the above command, you may refer to Used More Bash Utilities.

After that, since core.autocrlf has been set to false, git checkout no longer inserts \r into the files in the local repository. Therefore, even though git status reports unstaged changes, running git checkout -- source won’t hurt the files. I can finally deploy the contents to GitHub Pages.³

Lessons learnt

Never run rake generate nor rake preview in cmd.exe! Run this in Git Bash, or other shells that don’t give you carriage returns.

When a new post is created with rake new_post['...'] in either Git Bash or Command Prompt, the created post has DOS line endings. Therefore, we need to take extra care with this by using dos2unix in Git Bash.

---