Changing a Super Old Git Commit History

It used to be so simple.

I’d like to share a dilemma — and a strange solution.

Over 50+ commits ago, I had a “WIP” commit message that I never changed. The most straightforward solution it seems would be to get the SHA of that commit and run git rebase -i <SHA>.

Reword it? Not a problem.

Except.

Merge conflicts galore. The first few times, it was not a problem. I would fix the conflicts, add them, and git rebase --continue.

Until.

It kept escalating.

It wasn’t even a linear process, which made it even more confusing. It was unclear which version I should use most of the time. Plus, why am I even doing this? I’ve resolved these issues in the past. Why is changing the name of a commit message having these side effects?

While I cannot say that I have a resolution, I did find this solution (god bless Stack Overflow). I adapted the steps and did the following:

  • Went into/usr/local/bin (this could’ve been any usr directory)
  • Created a file called git-reword-commit (this could’ve been called anything so long as it starts with git). In that file, I added the following, based on the SO post (truthfully, I still need to decipher it):
#! /bin/bash
REV=$1
MESSAGE=$2
FILTER="test $(echo '$GIT_COMMIT') = $(git rev-parse $REV) && echo $MESSAGE || cat"
git filter-branch --msg-filter "$FILTER" -- --all
  • The SO post doesn’t say this, but you have to make sure the file is executable. Run chmod +x git-reword-commit
  • Returned to my repository and ran git reword-commit <SHA> "<MESSAGE"
  • git push -f

It 👏🏽 finally 👏🏽 worked 👏🏽 ! 🙌🏽

Show your support

Clapping shows how much you appreciated Malina Tran’s story.