Question

I made some source changes to lint my code. I did not run unit tests, and later I found that a large commit broke the code. How do I go back and find out which code change in a number of files broke the tests?

I could:

1. diff the working (earlier) commit against the breaking (later) commit
2. save the result in a patch file
3. patch/test cycle
   1. apply parts of the patch file to the earlier commit
   2. run the tests

I am hoping git has something less manual than this.

Answer 1

There’s a decent way to do this using the ability of git-stash to not only stash away and reapply changes, but also the state of the index. It goes something like this:

# check out the bad commit
git checkout bad-commit
# and then reset to the commit before, leaving the bad changes in the work tree
git reset HEAD^

# stage the things you want to keep/test first
git add -p
# stash away the rest (keep the staged parts)
git stash --keep-index
# now build/test. if it works, go ahead and commit it
git commit
# bring back the stashed changes
git stash pop
# repeat!
git add -p
git stash --keep-index
# now suppose the broken part is in what you kept, and you want to split it up more
# unstage the changes
git reset
# and then repeat!
git add -p
git stash --keep-index
# if you do this, you'll end up with multiple stashes; you can check on them:
git stash list
git stash show
git stash show -p stash@{1}

Using stashes and testing as you go along has the advantage that if you manage to pick a subset of the changes which simply breaks the build, you can just pop the stash back off, and try again.

You could do something similar to split up the commit into many, then run git bisect on it, but often that’s more work, since it’s more difficult to know how to split things up without testing as you go along.

Of course, now you know that you should make smaller commits. But I don’t always do it right the first time either!