Back merge to resolve conflicts

Posted Apr 20, 2023 11:05 UTC (Thu) by farnz (subscriber, #17727)
In reply to: Back merge to resolve conflicts by epa
Parent article: Avoiding the merge trap

This all starts to depend on the details of your workflow, and is thus challenging without knowing exactly how you work.

In the kernel workflow, you'd send your merge commit into main to upstream along with your topic branch, and let upstream make its decision about what to do from there - upstream can then see how you resolved conflicts (via your merge commit), and can either copy your resolution while doing their own merge, or merge your merge commit into their version of main, or rebase your merge commit. Up to them at this point, basically.

to post comments

Back merge to resolve conflicts

Posted Apr 20, 2023 11:44 UTC (Thu) by epa (subscriber, #39769) [Link]

Right, you can send upstream a particular commit, and they can apply it or merge it or whatever. I was stuck in the github/gitlab way of thinking, where I didn't see how I could send that commit to upstream because it didn't have its own branch to live on, and each merge request is for a particular branch.

In the end it boils down to the same thing. I can merge main into my branch, then send the result to upstream. Or I can merge my branch into main, and then send upstream that commit (with its ancestors). The only difference is which way round the commit graph is drawn.