CODEWITHSUNDEEP
gitgit-revert
hotcakedev
hotcakedev

Reputation: 2504

Revert the revert(un-revert) doesn't realize file changes in git?

How to revert the revert in general?

I used git revert -m 1 <commit-ID> to revert the reverted changes, and then pushed.

But I am not seeing any changes in my PR.

enter image description here

If I compare the master branch and the PR branch, I am able to see the differences and realize the PR has the correct commits that I am expecting.

enter image description here

How can you explain this and assuming this worked correctly?

Upvotes: 0

Views: 734

Answers (1)

torek
torek

Reputation: 487755

First, a bit of a side note: a revert that requires -m is reverting (undoing) a merge commit. That's why it requires the -m flag, to tell Git which parent to use. Commits that have multiple parents—i.e., merge cmmits—can't be shown as changes without some sort of redefinition of "changes" or other trickery. (That's what the -m is about: trickery to obtain a redefined "changes" so that the changes can be backed out.)

That aside, your PR branch appears to consist of exactly two commits:

  • First, there's a revert commit. This backs out some changes.
  • Then there's a revert of the revert. This backs out the backing out of the changes: the result is that the changes are back in.

Given:

...--G--H   <-- main
         \
          I--J   <-- pr

where commit I undoes H and then commit J undoes I, i.e., redoes H, we should expect the files in H to exactly match the files in J. That is, checking out commit H with:

git switch main

will produce some set of files, and then checking out commit J with:

git switch pr

will produce the exact same set of files. So comparing main (commit H) vs pr (commit J) would have zero files that are different, which is what you see. Here it doesn't matter whether H is actually a merge commit, except that to get I as a revert of H you would need the -m 1:

...--F
      \
       H   <-- main
      / \
...--G   \
          \
           I--J   <-- pr

If commit I's snapshot is the result of git revert -m 1 main, and commit J's snapshot is the result of git revert <hash-of-I> or equivalent, it's very likely that the files in J match the files in H. However, due to the fact that git merge can have conflicts, and reverting the merge can then produce further conflicts that could be resolved differently in I than they were when H was set up, it's possible (just unlikely) that J's snapshot would not match H's.

Upvotes: 1

Related Questions