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.
Merge conflicts galore. The first few times, it was not a problem. I would fix the conflicts, add them, and
git rebase --continue.
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
- 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):
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 👏🏽 ! 🙌🏽