Re: manual merge of the cix tree with the arm-soc tree
"Arnd Bergmann" <[email protected]>
| Newsgroups | dev.linux.lists.soc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-next |
|---|---|
| Message-ID | <[email protected]> |
On Sat, May 9, 2026, at 03:16, Peter Chen wrote: > On 26-05-08 13:06:02, Arnd Bergmann wrote: >> this is not a problem you caused, just something to be aware of >> when you send the pull request, and to check that Thierry made >> the right choice in resolving it. >> >> > Arnd, I deleted this patch at CIX next-tree. Would you please help queue it >> > in your soc/defconfig: >> > >> > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git/ >> > branch: cix/defconfig >> >> Please send it as a normal pull request or patch to [email protected] >> so your change gets mered using the patchwork process. >> >> If you send it as a standalone patch, please make sure it applies >> on top of the soc/defconfig branch. A pull request is also fine, >> and that would normally be based on -rc1. Obviously this causes >> a merge conflict, which we will resolve during the merge. > > Thanks for explaining it. So, for linux-next merge confliction patch, > how to handle it better? You have to look at each case separately. My comment above was about the defconfig conflict, which will be resolved as soon as the conflicting patches are both on the soc/defconfig branch. > Option 1: > Send pull-request to SoC maintainer once linux-next merge conflict > happens, and > depends on SoC maintainer's tree at linux-next for testing > Option 2: > Rebase on SoC maintainer's tree, and still keep patches on SoC > submaintainer's tree > at linux-next for testing > Other options? Neither of those really. You should send the pull requests for the SoC tree as soon as it makes sense for the contents to be merged. If you know that there is a conflict (because you got a message about it for linux-next), put that information into the pull request text so we know about it. If the conflict is against a change in some other tree, we still need to know about it, in order to plan the upstream submission. Most conflicts are entirely trivial to resolve, so upstream maintainers are usually ok with them. If you encounter something that does not look trivial, that usually means we need to talk about it and come up with a solution for that specific case. Arnd