Taco Steemers

A personal blog.

Automatically blocking a git commit if we detect a known mistake

Recently I made a mistake. As a result I was thinking about something I hadn't done in a while; making a git pre-commit hook . A pre-commit hook is code that runs before a commit, and can block the commit if there are any problems. People write git pre-commit hooks to help detect problems such as files with cross-platform encoding and line-ending issues, filenames that differ only in capitalization (1)☟ , and files that are not allowed to end up in a repository (2)☟ .

Another problem that we can fix with a git pre-commit hook is mistakes in URL linking spotted by Pelican. This can be found in the build output: WARNING: Unable to find '/articles/abc.html', skipping url replacement. We can check the build output for this type of problem. One way is to display the build output to the user but store it in a file as well. In the pre-commig hook we then check the build output for this type of problem.

Many pre-commit hooks have been shared online. You may be able to find some that are useful to you. For example, you will find various indentation related pre-commit hooks if you do a web search on "git pre-commit hook indentation".

What happened is that I updated my website, changed my mind about the title of the article I had just added, changed it, and updated the website again. The problem is that I also changed the slug to match the tile, which is what the URL is based on. This makes it look like a different article. It is possible that the article appeared twice some people's feeds, as it did in mine.

Not a big deal. Except that I don't like making mistakes. Especially if they are avoidable.

To make this type of mistake less likely I am adding two small pieces of automation. First is adding a small script that will detect if the RSS feed has changed even though it still contains the same number of article titles. This runs as a git pre-commit hook. This is what I am testing now . The basic idea works, but it does depend on using one commit per article. It does not work if we commit a new article at the same time that we change the slug on an existing article. To me that is acceptable; I already prefer that type of commit, where each commit represents one topic.

Second is adding some scripting that will work as a pelican pre-upload hook. The script will need to stop the upload if there are any modified files left. In other words, all files have been committed before we can upload the new website content. This way we know for sure the git pre-commit hook has been run.

Footnotes

1

Filesystems used by Windows ignore capitalization in filenames. Other filesystems do not. This results in problems when changing the capitalization of a version-controlled filename on a Windows computer. This change may not end up in a commit. As a result a build may succeed locally, but fails on other computers.

2

See my article "Some files and information should not be in source control" for reference. By creating a a pre-commit hook for these situations we can detect these types of files before we commit them.