Git-revert and “undoing” history
The first rule of git club is not to pretend like the past didn’t happen. That said, there are times when we want to roll back changes, especially if we are doing continuous deployment/integration where there is always supposed to be parity between the code in master and the artifact running in production.
We’ve all found ourselves in the situation where something got deployed, caused problems, and had to be rolled back. However, when that happens, it’s usually pretty fast: that is, we can “revert the last commit” and go back to how the world was a few minutes ago using git revert or git cherry-pick . What each of these do is create a “photographic negative” of the diff that produced the now-unwanted commit, apply it, and commit the result, which on the surface will appear identical to what we had before.
Well, that’s sort of true. If the unwanted commit was the result of several commits, then the diff will have several parts, and the reversion will take several commits. And so if you find yourself in the really unfortunate situation, as I did this week, of reverting to a commit pretty far back in the log, you might find that git revert abc123..HEAD just isn’t up to the job.
(Note to the maintainers: it really isn’t helpful to get an error message error: a cherry-pick or revert is already in progress on a clean working tree!)
After too many tabs of fruitless googling, though, we realized that, since we didn’t need to reapply the negative diffs separately in reverse order, we could create the patch ourselves:
git checkout -b revertToPrevious
git diff HEAD <previousCommit> > /tmp/old.patch
git apply /tmp/old.patch
git commit -a