I'm not completely sure what is the best practice for notifying Linus about conflicts which have already been resolved in linux-next. I presume they are a no-op to him, so maybe we shouldn't even call them out? That's the question I was hoping to answer by reading this doc :) For the small-time maintainers who aren't Linus including a lore link to the resolution from linux-next is the most optimal way in my experience. Sometimes people put the whole resolution diff into the PR message which occasionally confuses merge prep scripts making a mess of things... If Stephen already resolved the problem, just include the link. Cc: torvalds@xxxxxxxxxxxxxxxxxxxx Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> --- Documentation/maintainer/rebasing-and-merging.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/maintainer/rebasing-and-merging.rst b/Documentation/maintainer/rebasing-and-merging.rst index 85800ce95ae5..4134e63528fe 100644 --- a/Documentation/maintainer/rebasing-and-merging.rst +++ b/Documentation/maintainer/rebasing-and-merging.rst @@ -175,7 +175,11 @@ So what should a maintainer do when there is a conflict between their subsystem branch and the mainline? The most important step is to warn Linus in the pull request that the conflict will happen; if nothing else, that demonstrates an awareness of how your branch fits into the whole. For -especially difficult conflicts, create and push a *separate* branch to show +conflicts already resolved in linux-next include a lore link to the posted +resolution. + +For especially difficult conflicts and when linux-next resolution is +not available, create and push a *separate* branch to show how you would resolve things. Mention that branch in your pull request, but the pull request itself should be for the unmerged branch. -- 2.41.0
