Please read the Submitting Patches guidelines before reading this.
If you have a series of patches, it may be most convenient to have the maintainer pull them directly into their repository with a "git pull" operation. Note, however, that pulling patches from a developer requires a higher degree of trust than taking patches from a mailing list. As a result, many maintainers are reluctant to take pull requests, especially from new, unknown developers. If in doubt you can use the pull request as a cover letter for a normal posting of the patch series, giving the maintainer the option of using either.
A pull request should have [GIT] or [PULL] in the subject line. The request itself should include the repository name and the branch of interest on a single line; it should look something like:
Please pull from
git://git.ipfire.org/people/someone/ipfire-2.x.git upstream-changes
to get these changes:
A pull request should also include an overall message saying what will be included in the request, a "git shortlog" listing of the patches themselves, and a diffstat showing the overall effect of the patch series. The easiest way to get all this information together is, of course, to let git do it for you with the git request-pull command.
Signed pull requests
Some maintainers want to see pull requests from signed commits; that increases their confidence that the request actually came from you. Those maintainers will not pull from public hosting sites like GitHub in the absence of a signed tag.
The first step toward creating such tags is to make a PGP key and get it signed by one or more fellow developers. This step can be hard for new developers, but there is no way around it. Attending the summit can be a good way to find developers who can sign your key.
Once you have prepared a patch series in git that you wish to have somebody pull, create a signed tag with git tag -s. This will create a new tag identifying the last commit in the series and containing a signature created with your primate key. You will also have the opportunity to add a changelog-style message to the tag; this is an ideal place to describe the effects of the pull request as a whole.
If the tree the maintainer will be pulling from is not the repository you are working from, don't forget to push the signed tag explicitly to the public tree.
When generating your pull request, use the signed tag as the target. A command like this will do the trick:
git request-pull master git://git.ipfire.org/people/johndoe/ipfire-2.x.git my-signed-tag