Recently a friend turned me onto an interesting article about a problem I had just recently discovered about Git and its pre-commit hook:
Committing in git with only some changes added to the staging area still results in an “atomic” revision that may never have existed as a working copy and may not work.
As an example of this, I often find myself doing a whole flurry of changes all at once. This is no problem with Git, because I have the wonderful tool magit.el to help sift out the many commits implied by those changes. So I turn one big set of changes into many smaller commits, leaving only pending work in my working tree. Then I push.
My users pull those commits, only to find that lo! and behold, they will not build. “What?”, I think to myself, “how can that be? I just ran the unit tests and everything was fine.” However, I never ran the unit tests against that particular commit. Because those commits I just pushed never existed as independent working trees on my system. In fact, they never existed at all, they were mere figments within the Git index, which Git happily made into immutable commits for me.
What makes this all worse is that the pre-commit hook was something of a lie.
I thought that by adding make check to my pre-commit hook, I’d know for sure
that every commit I checked in was safe and sound. However, that make check
was running against my working tree, not the proposed commit. I still knew
nothing about the correctness of what I just checked in, unless it happened to
also represent the state of my working tree – a rare occurrence indeed, given
Git’s culture’s preference for frequent, smaller commits.
The answer turned out to be a little complex. What I needed was a pre-commit
hook that would test the contents of my Git index before each commit, not my
working tree. And there happens to be no simple command in Git for “checking
out your index”. Even if you do use git checkout-index, it resets the
timestamps for every files that it creates, forcing make check to rebuild the
entire app each time – not just its most recent changes. Assuming you have a
Makefile system that works, such duplication of effort is wholly unnecessary.
I came up with a solution that uses a secondary source tree, to hold the
checked out index, and a temporary build tree, which gets updated with any
changes since the last time the pre-commit hook was run. The end result is
that small changes pass or fail quickly, while large-scale changes sometimes
require a full rebuild to confirm.
The script itself can be viewed in my git-script project on GitHub. You will
need to tailor it for your own project if you plan to use it, and then copy it
to .git/hooks/pre-commit, and enable the executable bit.