Should change to code be committed separately from

Question

Should a code change and the corresponding change to the test suite be made in one commit, or split into two? Consider the case of a bug fix which causes a small change in the expected output, forcing a minor change in the test suite. It is extremely convenient to have both changes in the same commit, since it makes it obvious to the reviewer exactly what is changed in the output. On the other hand, sometimes you might just want to view the diffs to the source, or the diffs to the expected output and it is much easier to do that if the commits are separate. Also, the two things are logically distinct so it makes sense to make distinct commits.

I would love to be able to make two distinct commits, but somehow have the two commits linked together in some way (so that I can cherry-pick, revert, etc. both commits as an atomic unit). Also, if two distinct commits are made, then the test suite will fail on the first commit (unless a third commit is introduced to relax the test suite), making future bisects a pain. The issue of future bisects failing generally encourages me to make a single commit, but commits should be logically distinct units and a commit to code is logically distinct from a commit to the expected output in the test suite.

Is there a way to make two distinct commits and not have to bend over backwards to prevent bisect from failing on one of them? (eg, having to explicitly mention commits to skip)

Answer 1

If you like, you can keep them in separate commits in a development branch. After each pair of commits, merge into the feature branch. This should give you the ability to do either way.

Answer 2

Definitively keep those changes (code and unit test) as one commit: SCM is also about being able to reproduce a given state, and that include both the program and its tests.

If you need to review only code changes, do a git diff on src only, not on tst.
Since those linked changes remain in one commit, you avoid the bisect issue entirely.

In short, keep it simple ;)