git bisect
A practice’s contact form stopped lining up sometime in the last month and nobody knows when. Next to style.css in the theme folder on the server there’s style-backup.css, style-old.css, style-FINAL.css, style-FINAL-2.css, and 10 more along the same lines.
So I bisected it by hand. You copy one over style.css, reload, look, and put the real one back. If the form is broken in that copy, whatever broke it came before the copy. If it isn’t, it came after.
That only works if you know which copy is older and nothing here says, unfortunately. The modified dates all match because at some point the whole site got uploaded again in one afternoon. The names don’t help either since nobody can tell me whether old came before FINAL-2. I spent longer putting 14 files in order by diffing them than I spent halving them.
In git the order was never a question.
git bisect start
git bisect bad
git bisect good 3f9c2e1Git checks out a commit halfway between the two. You look and say git bisect good or git bisect bad, and it halves again. 300 commits is 9 of those. Then git bisect reset gets you back.
Either way you have to decide exactly what makes a version good or bad, out loud and before you start. “The form looks off” isn’t a test. “The submit button drops below the phone field at 1024px” is. If you can write that sentence as a script that exits non-zero, git bisect run ./check.sh does the whole thing unattended.
One other developer here and I have been making the case for putting the sites in git and mostly we’ve made it in the abstract. Nobody disagrees that history would be nice. I think a folder of 14 backups that can’t tell you what order they came in is a lot more persuasive than “would be nice.” That’s the version I’m bringing to the next conversation.