should use this space to describe what
has changed since your previous version, so that your reviewers have some idea
of what they're looking at. When the CI is done running, you can comment once
more with `/submit` - GitGitGadget will automatically add a v2 mark to your
changes.

[[howto-git-send-email]]
== Sending Patches with `git send-email`

If you don't want to use GitGitGadget, you can also use Git itself to mail your
patches. Some benefits of using Git this way include finer grained control of
subject line (for example, being able to use the tag [RFC PATCH] in the subject)
and being able to send a ``dry run'' mail to yourself to ensure it all looks
good before going out to the list.

[[setup-git-send-email]]
=== Prerequisite: Setting Up `git send-email`

Configuration for `send-email` can vary based on your operating system and email
provider, and so will not be covered in this tutorial, beyond stating that in
many distributions of Linux, `git-send-email` is not packaged alongside the
typical `git` install. You may need to install this additional package; there
are a number of resources online to help you do so. You will also need to
determine the right way to configure it to use your SMTP server; again, as this
configuration can change significantly based on your system and email setup, it
is out of scope for the context of this tutorial.

[[format-patch]]
=== Preparing Initial Patchset

Sending emails with Git is a two-part process; before you can prepare the emails
themselves, you'll need to prepare the patches. Luckily, this is pretty simple:

----
$ git format-patch --cover-letter -o psuh/ --base=auto psuh@{u}..psuh
----

 . The `--cover-letter` option tells `format-patch` to create a
   cover letter template for you. You will need to fill in the
   template before you're ready to send - but for now, the template
   will be next to your other patches.

 . The `-o psuh/` option tells `format-patch` to place the patch
   files into a directory. This is useful because `git send-email`
   can take a directory and send out all the patches from there.

 . The `--base=auto` option tells the command to record the "base
   commit", on which the recipient is expected to apply the patch
   series.  The `auto` value will cause `format-patch` to compute
   the base commit automatically, which is the merge base of tip
   commit of the remote-tracking branch and the specified revision
   range.

 . The `psuh@{u}..psuh` option tells `format-patch` to generate
   patches for the commits you created on the `psuh` branch since it
   forked from its upstream (which is `origin/master` if you
   followed the example in the "Set up your workspace" section).  If
   you are already on the `psuh` branch, you can just say `@{u}`,
   which means "commits on the current branch since it forked from
   its upstream", which is the same thing.

The command will make one patch file per commit. After you
run, you can go have a look at each of the patches with your favorite text
editor and make sure everything looks alright; however, it's not recommended to
make code fixups via the patch file. It's a better idea to make the change the
normal way using `git rebase -i` or by adding a new commit than by modifying a
patch.

NOTE: Optionally, you can also use the `--rfc` flag to prefix your patch subject
with ``[RFC PATCH]'' instead of ``[PATCH]''. RFC stands for ``request for
comments'' and indicates that while your code isn't quite ready for submission,
you'd like to begin the code review process. This can also be used when your
patch is a proposal, but you aren't sure whether the community wants to solve
the problem with that approach or not - to conduct a sort of design review. You
may also see on the list patches marked ``WIP'' - this means they are incomplete
but want reviewers to look at what they have so far. You can add this flag with
`--subject-prefix=WIP`.

Check and make sure that your patches and cover letter template exist in the
directory