meaningful and explain at a high level the purpose (what is happening and why)
of your patch, so you usually do not need any additional context. In that case,
remove the PR description that GitHub automatically generates from your commit
message (your PR description should be empty). If you do need to supply even
more context, you can do so in that space and it will be appended to the email
that GitGitGadget will send, between the three-dash line and the diffstat
(see <<single-patch,Bonus Chapter: One-Patch Changes>> for how this looks once
submitted).
When you're happy, submit your pull request.
[[run-ci-ggg]]
=== Running CI and Getting Ready to Send
If it's your first time using GitGitGadget (which is likely, as you're using
this tutorial) then someone will need to give you permission to use the tool.
As mentioned in the GitGitGadget documentation, you just need someone who
already uses it to comment on your PR with `/allow <username>`. GitGitGadget
will automatically run your PRs through the CI even without the permission given
but you will not be able to `/submit` your changes until someone allows you to
use the tool.
NOTE: You can typically find someone who can `/allow` you on GitGitGadget by
either examining recent pull requests where someone has been granted `/allow`
(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:
is:pr is:open "/allow"]), in which case both the author and the person who
granted the `/allow` can now `/allow` you, or by inquiring on the
https://web.libera.chat/#git-devel[#git-devel] IRC channel on Libera Chat
linking your pull request and asking for someone to `/allow` you.
If the CI fails, you can update your changes with `git rebase -i` and push your
branch again:
----
$ git push -f remotename psuh
----
In fact, you should continue to make changes this way up until the point when
your patch is accepted into `next`.
////
TODO https://github.com/gitgitgadget/gitgitgadget/issues/83
It'd be nice to be able to verify that the patch looks good before sending it
to everyone on Git mailing list.
[[check-work-ggg]]
=== Check Your Work
////
[[send-mail-ggg]]
=== Sending Your Patches
Now that your CI is passing and someone has granted you permission to use
GitGitGadget with the `/allow` command, sending out for review is as simple as
commenting on your PR with `/submit`.
[[responding-ggg]]
=== Updating With Comments
Skip ahead to <<reviewing,Responding to Reviews>> for information on how to
reply to review comments you will receive on the mailing list.
Once you have your branch again in the shape you want following all review
comments, you can submit again:
----
$ git push -f remotename psuh
----
Next, go look at your pull request against GitGitGadget; you should see the CI
has been kicked off again. Now while the CI is running is a good time for you
to modify your description at the top of the pull request thread; it will be
used again as the cover letter. You 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