-1

I am using semantic-release for automated versioning and releasing of my Git repository. However, I have made a mistake and committed a breaking change on the remote repository, and I want to change it to a fix or feature without altering the Git history.

Is it possible to do this using semantic-release, or is there another tool or method that can help me achieve this?

I don't want to alter the Git history because it can cause problems with other team members who have already pulled the changes.

Any help or advice would be greatly appreciated. Thank you.

user1512895
  • 113
  • 1
  • 1
  • 6
  • Given the limited information I would wager what's worse: breaking change causing issues for users of this software, or mildly inconveniencing other contributors? – Mike Szyndel Apr 05 '23 at 10:48
  • For example, if a pull request is made with this error in it, a reviewer sees that it is not a breaking change but a feature or even a patch. And you want to prevent this from causing a major version increase. – user1512895 Apr 05 '23 at 10:51

2 Answers2

1

committed a breaking change on the remote repository, and I want to change it to a fix or feature without altering the Git history

[Emphasis mine.]

Impossible. That's not what Git is. The most basic fact of Git is that no commit can be altered in any way. Anything you can imagine doing to this commit involves changing history.

Obviously you can counteract the breakage by appending a further commit (such as a revert). But you cannot turn this commit into anything else. You would have to forcibly replace this commit with a different commit, and that is changing history.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • I thought there might be a way to indicate in semantic-release that the previous commits could be ignored and thus fix this issue. – user1512895 Apr 06 '23 at 05:31
0

I have found this GitHub issue about it https://github.com/semantic-release/commit-analyzer/issues/232

you should avoid rewriting the history of any of the release branches. however, branches that are not release branches should be safe to amend. in fact, it is recommended to rewrite the history of complicated branches significantly before merging to a release branch in order to tell an appropriate story in the generated release notes

user1512895
  • 113
  • 1
  • 1
  • 6