docs/devel/submitting-a-patch.rst

78 line ``Based-on: $MESSAGE_ID`` to your cover letter to make the series
86 Split up longer patches into a patch series of logical code changes.
93 last, so that someone reading the series can do a clean-room evaluation
106 If a series requires large blocks of code motion, there are tricks for
107 making the refactoring easier to review. Split up the series so that
207 work with a full build before submitting a series, especially if your
215 your series fixes. Keeping separate commits for the test and the fix
217 the problem, then again to place it last in the series so that
247 Example workflow to prepare a patch series:
250 2. Create a new series with a topical branch name using ``b4 prep -n descriptive-name``.
276 <https://github.com/stefanha/git-publish>`__ to send series.
286 Each time you post a series, git-publish will create a local tag with the format
287 ``<branchname>-v<version>`` to record the patch series.
355 such as 'git-email' on Fedora-based systems.) Patch series need a cover
356 letter, with shallow threading (all patches in the series are
388 This is a requirement for any series with multiple patches (as it aids
390 letter explains the overall goal of such a series, and also provides a
391 convenient 0/N email for others to reply to the series as a whole. A
398 series, because they do not have enough context yet at that point of
399 their review. A series where the goal is unclear also risks a higher
404 entire series; potential reviewers know what files they are interested
405 in, and they need an easy way determine if your series touches them.
420    been accepted, so the QEMU patch series is blocked until that
449 Retrieve an existing series
452 If you want to apply an existing series on top of your tree, you can simply use
459 The message id is related to the patch series that has been sent to the mailing
461 of them can be used and b4 will apply the whole series.
467 process before they are accepted. This will often mean a series will
512 effort; repeatedly submitting a series without addressing all comments
523 patch series** not just the one patch that was changed. This allows
524 maintainers to easily apply the fixed series without having to manually
526 fresh email or series of emails -- don't try to make it a followup to
538 patch need not say "v1", just [PATCH] is sufficient.) For patch series,
539 the version applies to the whole series -- even if you only change one
540 patch, you resend the entire series and mark it as "v2". Don't try to
541 track versions of different patches in the series separately.  `git
584 When reviewing a large series, a reviewer can reply to some of the