I am trying to revert to an older commit but when I do, I get a merging conflict. Why does this happen?
Command I used:
git revert <commit id>
I am trying to revert to an older commit but when I do, I get a merging conflict. Why does this happen?
Command I used:
git revert <commit id>
Most update-the-index-and/or-worktree commands are some sort of merge, of the changes you want with the changes you have, both sets calculated from some base. The updates that aren't merges are generally (I can't think of an exception at the moment) called "hard" or "forced".
The base version (and the calculated changes) depend on what you're doing. For a revert, the changes you want are the ones that will take the commit[ted snapshot] you're reverting back to its parent, so the base is that reverting commit, the changes you want undo its differences from its parent, the changes you have are therefore the differences between that base, the one you're reverting, and your current checkout.
Git's rule for refusing to auto-merge is ~overlapping or abutting change hunks~. That rule has been tested by live fire: relax it and you get a raft of obviously-bad merges, tighten it and you reject a raft of basically-always-good merges.
The thing is, I think you're viewing merge conflicts as bad things. They're not. Git's telling you that the changes you want to apply, the ones that revert that commit to its parent version, overlap or abut changes you've already applied in your working copy (often enough just somewhere in the history since that commit you're reverting), and it's asking you what the result should look like: ~you want to apply this change, and you've already applied this other subsequent change, if I just moosh the results together history says the results won't be what anybody wants so check it out, fix it up, and add the correct result~.