Sending a Revised Patch Series with Git

psuh/*.patch ---- NOTE: Check `git help send-email` for some other options which you may find valuable, such as changing the Reply-to address or adding more CC and BCC lines. :contrib-scripts: footnoteref:[contrib-scripts,Scripts under `contrib/` are + not part of the core `git` binary and must be called directly. Clone the Git + codebase and run `perl contrib/contacts/git-contacts`.] NOTE: If you're not sure whom to CC, running `contrib/contacts/git-contacts` can list potential reviewers. In addition, you can do `git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch`{contrib-scripts} to automatically pass this list of emails to `send-email`. NOTE: When you are sending a real patch, it will go to git@vger.kernel.org - but please don't send your patchset from the tutorial to the real mailing list! For now, you can send it to yourself, to make sure you understand how it will look. After you run the command above, you will be presented with an interactive prompt for each patch that's about to go out. This gives you one last chance to edit or quit sending something (but again, don't edit code this way). Once you press `y` or `a` at these prompts your emails will be sent! Congratulations! Awesome, now the community will drop everything and review your changes. (Just kidding - be patient!) [[v2-git-send-email]] === Sending v2 This section will focus on how to send a v2 of your patchset. To learn what should go into v2, skip ahead to <<reviewing,Responding to Reviews>> for information on how to handle comments from reviewers. We'll reuse our `psuh` topic branch for v2. Before we make any changes, we'll mark the tip of our v1 branch for easy reference: ---- $ git checkout psuh $ git branch psuh-v1 ---- Refine your patch series by using `git rebase -i` to adjust commits based upon reviewer comments. Once the patch series is ready for submission, generate your patches again, but with some new flags: ---- $ git format-patch -v2 --cover-letter -o psuh/ --range-diff master..psuh-v1 master.. ---- The `--range-diff master..psuh-v1` parameter tells `format-patch` to include a range-diff between `psuh-v1` and `psuh` in the cover letter (see linkgit:git-range-diff[1]). This helps tell reviewers about the differences between your v1 and v2 patches. The `-v2` parameter tells `format-patch` to output your patches as version "2". For instance, you may notice that your v2 patches are all named like `v2-000n-my-commit-subject.patch`. `-v2` will also format your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]", and your range-diff will be prefaced with "Range-diff against v1". After you run this command, `format-patch` will output the patches to the `psuh/` directory, alongside the v1 patches. Using a single directory makes it easy to refer to the old v1 patches while proofreading the v2 patches, but you will need to be careful to send out only the v2 patches. We will use a pattern like `psuh/v2-*.patch` (not `psuh/*.patch`, which would match v1 and v2 patches). Edit your cover letter again. Now is a good time to mention what's different between your last version and now, if it's something significant. You do not need the exact same body in your second cover letter; focus on explaining to reviewers the changes you've made that may not be as visible. You will also need to go and find the Message-ID of your previous cover letter. You can either note it when you send the first series, from the output of `git send-email`, or you can look it up on the https://lore.kernel.org/git[mailing list]. Find your cover letter in the archives, click on it, then click "permalink" or "raw" to reveal the Message-ID header. It should match: ---- Message-ID: <foo.12345.author@example.com> ---- Your Message-ID is `<foo.12345.author@example.com>`. This example will be used below as well; make sure to replace it with the correct Message-ID for your **previous cover letter** - that is, if you're sending v2, use the Message-ID

This section explains how to send a revised version of a patch series, including how to mark the previous version, refine the patch series based on reviewer comments, generate new patches with a version number, and send the revised patch series with a new cover letter that highlights the changes made since the previous version.