Apart from lacking the convenience of a web interface, this process also puts considerable demands on the code contributions: the mails are expected to be plain text only (no HTML!), for example, and the diffs embedded in the mails must apply cleanly (no whitespace changes!), among other things.

Unlike most open source projects, Git itself does not accept code contributions via Pull Requests. Instead, patches are submitted to the Git mailing list for review and will be applied manually by the Git maintainer.

So you cloned https://github.com/git/git and implemented a bug fix or a new feature? And you already pushed it to your own fork? Good, now is the time to direct your web browser to https://github.com/gitgitgadget/git (or to https://github.com/git/git ) and to open a Pull Request. Please make sure to use a descriptive Pull Request title and description; GitGitGadget will use these as the subject and body of the cover letter (check out the MyFirstContribution tutorial if you are not familiar with this terminology). You can CC potential reviewers by adding a footer to the PR description with the following syntax:

CC: Revi Ewer <revi.ewer@some.domain>, Ill Takalook <ill.takalook@other.domain>

You will also want to read Git's contribution guidelines to make sure that your contributions are in the expected form, as well as the project's coding guidelines. You might also want to read the gitworkflows manual page to understand how your contributions will be integrated in Git's repository, as well as this note from Git's maintainer.

The first time you use GitGitGadget, you need to be added to the list of users with permission to use GitGitGadget (this is a very simple anti-spam measure). Any user who is already on that list can do that, by adding a comment to that Pull Request that says /allow <username> (with your GitHub login name).

The Pull Request will trigger a few Checks, most importantly one that will build Git and run the test suite on the main platforms, to make sure that everything works as advertised.