Note that putting the name of the remote (instead of a full URL) in the request-pull command will use the locally configured URL for that remote. So specifying the URL both times is only needed if one is ssh and the other is https, as in the example.
git.sr.ht/send-email.md | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/git.sr.ht/send-email.md b/git.sr.ht/send-email.md
index 84f632f..2464176 100644
--- a/git.sr.ht/send-email.md+++ b/git.sr.ht/send-email.md
@@ -120,6 +120,26 @@ prepare an additional email summary to be sent first.
**Note**: When you're prompted for an "In-Reply-To" header, you can ignore it
+## Using request-pull++Some maintainers may prefer to receive a "pull request", especially if you are+contributing a larger set of changes than can be easily managed in a handful of
+patches. You should likely already be discussing your changes with the+maintainers, so make sure you are clear on their workflow preferences.++To use this workflow you will need to have somewhere public to host your+modified copy of the git repository, such as right here on git.sr.ht. Add the+new remote:++ git remote add myfork firstname.lastname@example.org:~me/myfork++Then generate the pull request:++ git request-pull -p [rev-spec...] myfork++You can copy-paste the output into your email client (remember to ensure you+are not sending HTML email) and add any timely commentary in front.+## Handling feedback
You will likely receive replies to your email with feedback on your changes.