0

I am in a situation where I would like to edit the commit message of an old, already pushed code. In my case I have , of course, my master branch and several other branches, for example v1.0, v2.0 and v3.0. The commit I want to update its messages was made at the time when the branch v1.0 was the 'master'. At each new release of my code I also put a tag on each branch to start and later to follow the different fixes (1.0, 1.1, and so on). For example in branch v1.0, I have a fix (which represents a new version) tagged as 1.1. In my case the code where the commit messages appears is under the tag 1.0. I tried the whole procedure described here https://help.github.com/articles/changing-a-commit-message/ (Amending the message of older or multiple commit messages) but I am still being displayed the commit messages appear "under" the tag 1.0 (I am using SmartGit , that's why I am saying "under"). If I type git show commit_id I still see the commit with the old message...

Does anybody has an idea how to remove this commit message completely from git? Thanks in advance for the replies.

(I am not very good with git, so for now I am just trying to follow the explanations given in internet...)

May be I can recreate the repository and change these commit messages and at the same time keep the rest of the repository's history ? Someone may be did already that ? :)

Anton
  • 41
  • 8
  • You shouldn't edit the commit message of old, already pushed code, because that will change your history and effectively break your repository. – jonrsharpe Jun 25 '18 at 16:11

2 Answers2

1

Changing the commit message or the parent commit changes the commit ID which means as far as git is concerned it is a different commit.

If you want to change tags to point at your modified history you will need to find the corresponding commit in your modified history, point the tag at the new commit and then force push it (see https://stackoverflow.com/a/21127037/5083516 )

But in general changing published history in git is a bad idea and should only be done in extreme circumstances, not merely to correct minor mistakes. Anyone who cloned your repo prior to the history change and then tries to pull is likely to end up in merge hell.

plugwash
  • 9,724
  • 2
  • 38
  • 51
  • I am not sure if this will do the thing... If I move the tag, what will happen with the "old" commits and their messages ? And in my case I have this: comit1, comit2, myComit1, comit3, myComit2, commit4 (tagged - 1.0). If I change the myComit* messages, the tag does not moves, it is still pointing to the commit4. – Anton Jun 25 '18 at 16:48
  • @Anton: The old commits remain, up until everyone who was using them has converted *their* repositories (which have copies of every commit) to use only the new commits and stop using the old ones. For tags, this generally means that after you force-push the tag to point to the replacement commit, all other users must run `git fetch --tags`. If any of them force-push the old tag, the old commit becomes visible to all again as well. It's very hard to get rid of a commit once it's spread in the wild. – torek Jun 25 '18 at 17:20
0

Given no-one has pushed anything upstream since you pushed your commit, you can use:

git push --force-with-lease

after you changed your commit locally via --amend.

This is explained in your link though. I assume you didn't fetch from the repository after pushing the amended commit? The problem may be caused by your tool, try re-importing the whole repository.

SpoonMeiser
  • 19,918
  • 8
  • 50
  • 68
ggradnig
  • 13,119
  • 2
  • 37
  • 61
  • Thank you for the suggestion! Unfortunately, I see the old messages on the git server... If I clone the repository in a new directory I still have the old commit messages... As I said, it is in an old version where the message appears, so there are many other commits coming after. – Anton Jun 25 '18 at 16:39