Lines Matching full:the

7 sent as simple patch emails to the mailing list (see our page on
17 **Resend the patches with the pull request** as emails which are
18 threaded as follow-ups to the pull request itself. The simplest way to
19 do this is to use ``git format-patch --cover-letter`` to create the
20 emails, and then edit the cover letter to include the pull request
23 **Use PULL as the subject line tag** in both the cover letter and the
26 helps people to filter in or out the resulting emails (especially useful
27 if they are only CC'd on one email out of the set).
30 the original author if the patch was not written by you. This is because
31 with a pull request you're now indicating that the patch has passed via
32 you rather than directly from the original author.
35 people have reviewed the patches you're putting in the pull request,
36 make sure you've copied their signoffs across. (If you use the `patches
38 directly to your git repo it will include the tags automatically; if
40 edit the commit messages by hand.)
44 have passed the standard code review processes. In particular if you've
46 fixed patch series as normal to the list; you can't put it in a pull
48 just fix in passing, but if in doubt err on the side of not.)
51 everything builds (including that it compiles at each step of the patch
52 series) and that "make check" passes before sending out the pull
54 against bad code, so double check the details.
57 the pullreq email should quote a tag which is a GPG-signed tag (as
62 "PULL SUBSYSTEM whatever" in the subject tag**. If your pull request is
63 targeting a stable branch or some submaintainer tree, please include the
64 string "not for master" in the cover letter email, and make sure the
66 "PULL". This allows it to be automatically filtered out of the set of
69 You might be interested in the `make-pullreq