0

I am trying to modify commits from before a merge where I had to solve conflicts (especially, I want to squash a new commit into one before the merge, but just rewriting commit messages lead to the same issue).

When I use:

git rebase -i --rebase-merges SHA~1

I have to resolve the conflicts of the merge again, this is really time consuming and I don't understand why the conflicts appear again.

Is there a way to modify commits before a merge with conflicts without having to resolve the conflicts again ?

Antonio Petricca
  • 8,891
  • 5
  • 36
  • 74
Puck
  • 2,080
  • 4
  • 19
  • 30

1 Answers1

1

A regular rebase copies commits as if with (or sometimes literally with) git cherry-pick, and each cherry-pick operation is a merge. A --rebase-merges rebase copies merges by re-performing the merges on the new copies of the old commits made with the earlier cherry-pick steps. So if there are 47 original commits to copy, 3 of them being merges, you'll have 44 opportunities for git cherry-pick to produce merge conflicts, and 3 more for git merge to produce conflicts.

If you had conflicts before, it's very likely you will have the same ones again. Here, git rerere can be quite helpful. There is talk of turning it on by default in future Git releases. Until then, since you already have some merges, consider using rerere-train: see Smarter rebase avoiding redundant work? See also What is git-rerere and how does it work?

torek
  • 448,244
  • 59
  • 642
  • 775