Lines Matching full:patch
27 Applying the patch to a tree
30 Sometimes the patch you are backporting already exists as a git commit,
32 ``git cherry-pick``. However, if the patch comes from an email, as it
37 quite picky about the patch applying perfectly to your source tree. In
39 edit the patch to make it apply.
42 where the patch applies cleanly and *then* cherry-pick it over to your
46 apply a patch that just arrived on LKML to an older stable kernel, you
50 It's generally better to use the exact same base as the one the patch
53 problem with applying the patch to the "wrong" base is that it may pull
60 it less likely to apply the patch to the wrong place (which can result
63 If you are using `b4`_. and you are applying the patch directly from an
69 .. _b4: https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
72 Once you have the patch in git, you can go ahead and cherry-pick it into
74 written record of where the patch came from!
76 Note that if you are submitting a patch for stable, the format is
95 In general, conflicts appear when the context of the patch (i.e., the
97 match what's in the tree you are trying to apply the patch *to*.
149 your resolution. As an added bonus, especially if the patch is in an
162 the patch you are picking (``<commit>``), i.e.::
199 need to run it against the parent commit of the patch you are
211 the blame output is the commit ID of the patch that added a given line
226 Having found the patch that caused the conflict, you need to determine
227 whether it is a prerequisite for the patch you are backporting or
228 whether it is just incidental and can be skipped. An incidental patch
229 would be one that touches the same code as the patch you are
231 material way. For example, a whitespace cleanup patch is completely
232 incidental -- likewise, a patch that simply renames a function or a
236 patch adding the function should be cherry-picked first.
238 If you find that there is a necessary prerequisite patch, then you need
245 with the commit ID of the prerequisite patch instead.
261 this is what the patch wants it to be after cherry-picking
273 + this is what the patch wants it to be after cherry-picking
284 after the original patch has been applied.
306 +this is what the patch wants it to be after cherry-picking
311 because they are part of the merge conflict or the patch being
324 this is what the patch expected to find there
326 this is what the patch wants it to be after being applied
331 this conflict style as it makes it much clearer what the patch actually
350 patch you are backporting. For the Linux kernel this is especially
354 Understanding the patch can be easy or difficult depending on the patch
356 However, a good question for every change (or every hunk of the patch)
357 might be: "Why is this hunk in the patch?" The answers to these
365 the changes by hand. Perhaps the patch is changing a function call
378 what your patch looks like so far.
384 patch is discovering that one of the files being patched has been
389 There are generally a few ways to deal with this. If the patch to the
402 Sometimes the right thing to do will be to also backport the patch that
406 attempt to cherry-pick the patch, rename the file back (``git mv`` and
428 If you cherry-pick a patch that includes a ``goto`` statement (typically
441 function that's being changed in a patch. One of the things that often
454 backporting: a patch to a single location may need to be applied to
460 patch fixes a bug that appears in more than one place. One way to do
464 places exist upstream -- if they don't, it's likely the patch may need
471 patch author. It's not uncommon to find new bugs during backporting!
479 Having committed a conflict-free new patch, you can now compare your
480 patch to the original patch. It is highly recommended that you use a
503 changed labels between the original and backported patch, colordiff will
506 labels. Likewise, lines that were not modified by either patch but
517 just the files touched by the patch as a quick sanity check. For the
538 entry code where the first patch saved/restored a register and a later
539 patch made use of the same register somewhere in the middle of this
541 cherry-pick the second patch, have no conflicts, and believe that
547 a backport is to review the final patch with the same level of scrutiny
548 as you would (or should) give to any other patch. Having unit tests and
560 the patch to the correct tree and submit the patch.
565 <original patch title>
578 It is most common to indicate the kernel version the patch applies to
580 ``git send-email --subject-prefix='PATCH 6.1.y'``), but you can also put
590 2) Understand the patch you are backporting; this means reading both
593 patch.
599 The above shows roughly the idealized process of backporting a patch.