In a recent conversation on Twitter, the question of whether all individual git commits should compile* was discussed.
There’s broadly two answers to this:
and which one you choose is more a function of your workflow and practices than a definitive answer one way or another.
To explain what I mean by the ‘no’ answer above; if you have a series of
commits in a repository (let’s call them
denote them), provided that the final commit
compiles* successfully or not, does it really matter whether
b do as well?
For a local repository that you’re working on, it doesn’t matter too much; after all, local git history is mutable. It’s when you start pushing to remote branches – particularly ones others can see – that rewriting history is generally frowned upon.
These two patterns collide when it comes to shared code reviews. You’d like
to get early feedback on an implementation, so you share it with others
via some kind of remote repository/branch; but when you do, the expectation
is that you’ll build upon it by adding further commits
c→d→e) instead of replacing ones you’ve already
These two patterns are exemplified by GitHub’s pull requests and Gerrit’s reviews.
A GitHub branch or pull request is typically additive; newer commits amend changes until the feature is complete, upon which the pull request is merged. In this case what’s being reviewed is not necessarily the history that got to that point, but the resulting effect this change has on the branch it is being merged into. The result of the pull effect, not how it got there, is the thing being measured.
Gerrit’s reviews on the other hand allow you to review commits on a commit-by-commit basis; in other words, reviewing the history. Implicitly this ends up reviewing the resulting change as well, but through a bottom-up rather than top-down view. If an issue is found, the original commit needs to be edited and rebased before being pushed again.
In both cases it’s possible to set up a trigger, such that when a change occurs the compiler* is invoked and marks the change as verified or not; but in Gerrit’s case, it will do this for every commit in the history whereas in GitHub’s case it will just do this for the branch as a whole.
There are a couple of reasons for this differences, which are more to do with environment than anything else.
Secondly, the ability for each commit to be compiled or not is of assistance
git bisect. For those that haven’t used it before (or read the
git tip of the week
on the subject), git bisect allows you to run a program to determine ‘good’ or
‘bad’ and then perform a binary search to find out when ‘good’ changes to
In the case of code at least compiling correctly, it’s possible to run the output in some form of test harness or against a test case to determine whether the resulting code is good or not; but if the code haphazardly doesn’t compile correctly then the problem can be more challenging to resolve.
As a result, those who use
git bisect tend to value the benefits of each
individual commit compiling correctly, whereas those who either don’t need
to do a compile step or are forward-looking with roll forwards tend to
not need it.
So the summary is; it’s really up to taste. If you’re using a compiled
language, and you want to be able to use
git bisect effectively, then
having every commit compile can be a valuable tool. But if you’re not
using a compiled language, and don’t have a sequence of tests that you
can run, then ignoring the interim state and focussing on the final result
can be more agile.
Updated Thanks to
for pointing out I meant
git bisect instead of