4

I have a case where just doing git rebase HEAD~10 produces multiple merge conflicts.

As I understand it the command above should revert to HEAD~10 and then cherry-pick every commit since then over it without any changes, thus simply repeating history.

How is it possible for this to produce merge conflicts?

I will not post the specific case as I don't want to turn this question into specific problem-solving (I have actually no reason to do that rebase), but I'm rather trying to understand how git works.

EDIT:

Adding a network graph, to illustrate things better. The conflict occurs when the rebase goes as far as the "More tests" commit

Network

qwazix
  • 906
  • 11
  • 17

2 Answers2

2

That probably happens if your last 10 commits contain a merge commit. Rebasing will linearize the history by default unless you specify --preserve-merges / -p and thus get rid of any merge conflict resultions from merge commits in the history, so you will run into these conflicts again.

sschuberth
  • 28,386
  • 6
  • 101
  • 146
  • 1
    Note that if you resolved a conflict in a merge that you replay with `git rebase -p`, Git will have to resolve the same conflict in the same merge. The reason is that "merge preserving" is really "merge re-doing". If you have enabled `git rerere` Git will re-use your existing, recorded resolution, but most of us don't and would have to re-do the conflict resolution manually. – torek Nov 11 '16 at 16:10
  • Actually there is a merge 1 commit further back in the history. I don't remember if that required conflict resolution, it's possible. However the fact that the conflict appears when applying "More tests" rather than "First successful analysis" still bugs me – qwazix Nov 14 '16 at 13:05
1

As I explained in detail in "Why does this cherry-pick have a conflict?", try the same rebase after:

git config merge.conflictstyle diff3

You will see (when there is a conflict after a cherry-pick is applied during the rebase) that there is no common ancestor.

Cherry-picking takes a commit and applies the change that it introduces.
That means if the introduced changes are introduced on top of other changes that the destination does not have... conflict.
(Again, "Why does this cherry-pick have a conflict?" illustrates that case)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • If that's the cause of the issue, the OP might be able to work around it by passing `--merge` / `-m` to `git rebase` to make it "Use merging strategies to rebase". – sschuberth Nov 11 '16 at 20:12
  • You're saying that it doesn't know whether to apply "More tests" on top of "Some tests" or "First successful analysis"? (Image above) – qwazix Nov 14 '16 at 13:06
  • @qwazix it knows what commit to apply, not what content within that commit: read http://stackoverflow.com/a/38989749/6309 – VonC Nov 14 '16 at 13:12
  • I did read that, but in that case the OP tries to apply a commit to a state several commits back. It's very logical that it won't succeed as it can't find where to do the changes. In my case, it's just replaying the commit on the immediately previous commit, thus AIUI it's impossible to not know what content to apply. – qwazix Nov 14 '16 at 14:04
  • @qwazix Did you try with `git config merge.conflictstyle diff3` activated? When a conflict occurs, what do you see in the common ancestor section? – VonC Nov 14 '16 at 14:21
  • Now I have, but as I suspected it didn't help. The conflict is in a generated IDE file (.idea/workspace.xml) so I can't really grok anything by watching the diff. In the common ancestors sections there are some conflicting values. – qwazix Nov 16 '16 at 06:35
  • After digging into the commits, I see one of the "common ancestors" in the immediately previous commit, but I can't find the other one anywhere in the project. I vgrepped the few commits before the weird one, and then the whole history via gitlab – qwazix Nov 16 '16 at 06:44