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). - GitGitGadget tries a different approach: allow contributing patches to the Git project itself by opening a Pull Request at https://github.com/gitgitgadget/git and let GitGitGadget prepare and send the corresponding mails. + 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.
@@ -54,16 +99,21 @@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 and to open a Pull Request. - Please make sure to use a descriptive Pull Request title and description; GitGitGadget will use these as the cover letter. - You will also want to read Git's guidelines to make sure that your contributions are in the expected form. + 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).
+ 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 /submit.
+ Once everything is ready to go, add a comment to that Pull Request saying /submit.
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.
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 /submit.
+ 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 /submit.
+
+ 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.
+| Features | +gitgitgadget/git | +git/git | +
|---|---|---|
| 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 pu, next, master and maint |
+ ✓ | +✓ | +
Adds a label to the PR when the series is integrated into pu, next, master and maint |
+ ✓ | +✓ | +
PRs can target pu, next, master and maint |
+ ✓ | +✓ | +
PRs can target any topic branch in the maintainer's fork, as well as git-gui/master |
+ ✓ | +✗ | +
| 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 | +✓ | +✗ | +