3

Is there a way to automatically merge (interdiff) conflicts between 2 head branches and 1 base branch?

I was trying to do it at the patch level

  • VersionA is my base

  • VersionB is branched from VersionA

  • VersionB has an additional mod applied, Base+ModB

  • VersionC is branched from VersionA

  • VersionC has an additional mod applied, Base+ModC

Manually applying patches, I can derive a A:B and a A:C patch, and apply them to version A sequentially. However, if the two conflict in the areas they apply in (such as editing the same area), they break.

I've tried various tools like interdiff and combinediff to create a combined patch manually to no success (I'm on windows, and interdiff is cygwin compatible, but I don't know if UNC are an issue, so far I don't think so), specificying such as outputs as Unified vs Contextual due to interdiff/combinediff requirements.

So... is there a way I can do a Version A as my Base, and a combined changes of version A:B && A:C as my head? And do some sort of 3-way pull request?

If any conflicts arise, I would hope git would be able to address them intelligently by doing it's infamous >>>> and ===== and <<<<< merging of conflicts, which is completely acceptable at this point.

Ultimately, I'd like to figure out a way to do this on a patch level by combining patches. I see that git(hub) has some options for working with 3 way patches and emailing patches with git apply and git patch and git format-patch.

this also helped: Git pull gives conflicts with octopus strategy

Although I'm not pulling from remote and pull is merge when working locally (the command works the exact same pretty much).

Community
  • 1
  • 1
thistleknot
  • 1,098
  • 16
  • 38

1 Answers1

2

The closest would be an octopus merge (merge of multiple HEADs):

git merge B C

Note that the order can be important: "Git octopus merge order of multiple branches".

The OP thistleknot adds in the comments:

The merge didn't work initially until I figured I had branched off a common ancestor at the "wrong point" more or less.
I didn't know it until I looked at the merge*.* output files and saw each merge file was a source file. One from Version B and Version C and the common ancestor of B and C. Once I figured that out, I was able to do some more branching magic, and the merge worked, with the <<< and ====

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • thank you, someone else said I should look into that or rebasing. I appreciate it, I'll try it out and see how it goes. – thistleknot Aug 20 '14 at 14:04
  • Thank you. The merge didn't work initially until I figured I had branched off a common ancestor at the "wrong point" more or less. I didn't know it until I looked at the merge*.* output files and saw each merge file was a source file. One from Version B and Version C and the common ancestor of B and C. Once I figured that out, I was able to do some more branching magic, and the merge worked, with the <<< and ==== :) – thistleknot Aug 20 '14 at 15:27
  • @thistleknot great! I have included your comment in the answer for more visibility. – VonC Aug 20 '14 at 15:32