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.
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.
A few tutorials out there try to help with this process (e.g. Git for Windows' detailed instructions how to contribute patches to the Git project, or Git's MyFirstContribution tutorial). GitGitGadget tries a different approach: allow contributing patches to the Git project itself by opening a Pull Request either at https://github.com/gitgitgadget/git or directly at https://github.com/git/git and let GitGitGadget prepare and send the corresponding mails.
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. A few things to note about a GitGitGadget Pull Request:
CC: Revi Ewer <email@example.com>, Ill Takalook <firstname.lastname@example.org>
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.
Once everything is ready to go, add a comment to that Pull Request saying
This will trigger GitGitGadget (you can see the progress via the Check called "GitGitGadget PR Handler"): it will wrap your Pull Request into a nice bundle of mails in the format expected on the Git mailing list.
The patches will be reviewed by volunteers (be gentle...) and you will most likely receive helpful comments. The Git developer community is globally distributed, so please wait a day or two for reviewer comments to trickle in before sending another iteration of your patch series (if needed).
In the case that a reviewer asks for changes, you should respond either acknowledging that you will make those changes or making an argument against the requested changes.
If your patches need to be revised, please use
git rebase -i to do that, then force-push, then update the description of the Pull Request by adding a summary of the changes you made, and then issue another
GitGitGadget works on both GitGitGadget's Git fork (https://github.com/gitgitgadget/git) and Git's GitHub mirror (https://github.com/git/git). However, some functionality is only available when opening a PR on GitGitGadget's Git fork.
|Mirrors emails answers as PR comments||✓||✓|
|Mirrors PR comments as emails to the list||✗||✗|
|Builds Git and runs the test suite on Linux, macOS, Windows and FreeBSD||✓||✓|
|Comments on the PR when a topic branch is created in the maintainer's fork||✓||✓|
|Comments on the PR when the series is integrated into
|Adds a label to the PR when the series is integrated into
|PRs can target
|PRs can target any topic branch in the maintainer's fork, as well as
|Creates a direct link between the last commit of the series and the corresponding commit in the "most upstream" integration branch as a GitHub check||✓||✗|