0

I'm not sure if this is possible but I've looked around and I've not seen anything. Don't even know how I would wrap my head around it.

Is it possible and if so, how, to undo/remove only specific characters in a git commit?

For example, imagine making a commit that makes changes to a codebase file with many characters changes

== to === // for if checks
is_null() to === null

and you want to undo only the change of character "=" from the commit and the rest should remain intact.

Thanks for your help in advance!

Derick Alangi
  • 1,080
  • 1
  • 11
  • 31

2 Answers2

2

No, it is not possible to change anything about any commit.

The reason is that the commit's identity is its hash ID, and its hash ID is a cryptographic checksum of its content. So if you do manage to change its content, you have a new and different commit.

There's nothing wrong with that—you can say: Hey everybody, forget about commit badf00d, use my fixed-up commit whose ID is cafedad. But you didn't change the commit, you just made a new improved one instead.

The drawback here is that someone might be building stuff on the old, wrong commit. They'll have to do something to switch to building their stuff on the new improved commit. That's not hard, but it's mildly annoying. It's easier to leave the old, wrong commit in and simply put a corrected commit in afterward: Hey everybody, commit badf00d has a bug, it's fixed in the follow-up commit f100ded. That particular work-flow—picking up new commits that add on to existing ones—is something everyone must be able to do at all times, so it's easier.

The choice (of whether to force others to switch) is yours.

(If your interest is in the mechanics, of how to accomplish these various actions—telling people to forget about the bad commit in favor of the good one, in particular—that's a different question. But it's already answered here on StackOverflow.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • 1
    Unless there was a `git push`, all commits are local and are malleable, you can edit them at will without affecting anyone. – Krzysiek Karbowiak Feb 25 '19 at 13:39
  • @KrzysiekKarbowiak: Sure, but they're not *malleable*, they're *replaceable*. The replacement still happens. Nobody else need know that you did it, but it's important to note that you haven't actually *changed* some existing commit. This matters if you have your own "downstream" commits—it's why you need to use `git rebase -i` and `edit` rather than just `git commit --amend` here. – torek Feb 25 '19 at 14:29
  • You are absolutely right. I wrote malleable, as you see the new commit in place of the old one, and if you don't look at the hash (and who really does), it seems that the commit was modified. But in fact it was not, it was replaced. – Krzysiek Karbowiak Feb 26 '19 at 07:22
  • "If you don't look at the hash" :-) The problem here is that the "I changed the commit" mental model works up until you create a new branch or tag name and *then* use `git commit --amend`. Suddenly your *current* branch has the "changed" commit, but the new branch or tag still has the old one. So I think it's best to keep thinking of this as "replace"... – torek Feb 26 '19 at 15:47
0

There are ways to change things (git amend), but the problem is you pushed your modifications already. This means if somebody pulled it, you will experience issues becaue you will have different trees. See this for how to do it, and why you should avoid doing it:

How do I push amended commit to the remote Git repository?

Most of the time, it is simpler to create a new commit with these extra-changes. The ony cases in which I absolutely wanted to change an upstream repo was when removing a file from the repo history (which requires re-creating commits).

How to remove/delete a large file from commit history in Git repository?

Tom
  • 834
  • 1
  • 14
  • 24