Lines Matching full:you
21 techniques you can use to make the process smoother and increase your
30 Sometimes the patch you are backporting already exists as a git commit,
31 in which case you just cherry-pick it directly using
33 often does for the Linux kernel, you will need to apply it to a tree
36 If you've ever used ``git am``, you probably already know that it is
38 fact, you've probably had nightmares about ``.rej`` files and trying to
44 you resolve conflicts with the help of git and any other conflict
45 resolution tools you might prefer to use. For example, if you want to
46 apply a patch that just arrived on LKML to an older stable kernel, you
63 If you are using `b4`_. and you are applying the patch directly from an
64 email, you can use ``b4 am`` with the options ``-g``/``--guess-base``
67 article will assume that you are doing a plain ``git cherry-pick``.
72 Once you have the patch in git, you can go ahead and cherry-pick it into
73 your source tree. Don't forget to cherry-pick with ``-x`` if you want a
76 Note that if you are submitting a patch for stable, the format is
97 match what's in the tree you are trying to apply the patch *to*.
99 For backports, what likely happened was that the branch you are
100 backporting from contains patches not in the branch you are backporting
105 edits the files to include so-called conflict markers showing you where
114 conflict directly, as it may be easier to understand what you're doing
119 pointers to various tools that you could use:
139 Most conflicts happen because the branch you are backporting to is
140 missing some patches compared to the branch you are backporting *from*.
148 conflict, as otherwise you cannot be confident in the correctness of
150 area you're not that familiar with, the changelogs of these commits will
151 often give you the context to understand the code and potential problems
160 frequently patched. You should run ``git log`` on the range of commits
162 the patch you are picking (``<commit>``), i.e.::
166 Even better, if you want to restrict this output to a single function
167 (because that's where the conflict appears), you can use the following
176 if you use ``-L:thread_stack:kernel/fork.c`` it may only give you
181 Another useful option for ``git log`` is ``-G``, which allows you to
182 filter on certain strings appearing in the diffs of the commits you are
189 string is a regular expression, which means you can potentially search
198 one for a given conflict) is to run ``git blame``. In this case, you
199 need to run it against the parent commit of the patch you are
205 output to a single function), but in this case you specify the filename
219 the latter case, you may have to run ``git blame`` again and specify the
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
229 would be one that touches the same code as the patch you are
235 not be incidental at all and you need to carefully consider whether the
238 If you find that there is a necessary prerequisite patch, then you need
239 to stop and cherry-pick that instead. If you've already resolved some
240 conflicts in a different file and don't want to do it again, you can
253 Let's say you've decided against picking (or reverting) additional
254 patches and you just want to resolve the conflict. Git will have
264 This is what you would see if you opened the file in your editor.
265 However, if you were to run ``git diff`` without any arguments, the
276 When you are resolving a conflict, the behavior of ``git diff`` differs
293 file between your current branch and the branch you are cherry-picking
294 from. While this is useful for spotting other changes that you need to
296 intimidating and difficult to read. You may instead prefer to run
309 As you can see, this reads just like any other diff and makes it clear
329 As you can see, this has 3 parts instead of 2, and includes what git
332 changed; i.e., it allows you to compare the before-and-after versions
333 of the file for the commit you are cherry-picking. This allows you to
336 To change conflict marker styles, you can use the following command::
350 patch you are backporting. For the Linux kernel this is especially
371 pulled in a lot of unrelated context that you don't really need to care
374 For particularly nasty conflicts with many conflict markers, you can use
376 get them out of the way; this also lets you use ``git diff HEAD`` to
387 You do the work..."
392 other hand, if the change is big or complicated, you definitely don't
395 As a first pass, you can try something like this, which will lower the
404 what you can do is to temporarily rename the file in the branch you're
408 (see the `rebase tutorial`_) so it appears as a single commit when you
428 If you cherry-pick a patch that includes a ``goto`` statement (typically
430 the target label is still correct in the branch you are backporting to.
438 A good way to ensure that you review the error paths is to always use
440 inspecting your changes. For C code, this will show you the whole
443 on either of the branches that you're backporting from or to. By
444 including the whole function in the diff you get more context and can
453 has taken place, you effectively need to do the reverse when
462 in general, not just for backports.) If you do find that the same kind
466 to these areas as ``git blame`` won't show you code that has been
469 If you do find other instances of the same pattern in the upstream tree
470 and you're not sure whether it's also a bug, it may be worth asking the
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
493 giving you just the diff for that single commit; also see
499 you will see the full function for any function that has changed.
518 Linux kernel you can build single files like this, assuming you have the
523 Note that this won't discover linker errors, so you should still do a
525 the single file first you can avoid having to wait for a full build *in
526 case* there are compiler errors in any of the files you've changed.
548 as you would (or should) give to any other patch. Having unit tests and
559 These emails typically include the exact steps you need to cherry-pick
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