| Message ID | 20191026005159.98405-4-emilyshaffer@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | some clarifications to MyFirstContribution | expand |
Emily Shaffer wrote: > GitGitGadget, a handy tool for converting pull requests against Git into > Git-mailing-list-friendly-patch-emails, requires as anti-spam that all > new users be "/allow"ed by an existing user once before it will do > anything for that new user. While this tutorial explained that > mechanism, it did not give much hint on how to go about finding someone > to allow your new pull request. So, teach our new GitGitGadget user > where to look for someone who can add their name to the list. > > The advice in this patch is based on the advice proposed for > GitGitGadget: https://github.com/gitgitgadget/gitgitgadget/pull/138 > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com> > --- > Documentation/MyFirstContribution.txt | 8 ++++++++ > 1 file changed, 8 insertions(+) Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Though I'd appreciate an ack from a gitgitgadget specialist too, so cc-ing Dscho. > diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt > index b8ffeda07e..2de06de026 100644 > --- a/Documentation/MyFirstContribution.txt > +++ b/Documentation/MyFirstContribution.txt > @@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given > but you will not be able to `/submit` your changes until someone allows you to > use the tool. > > +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by > +either examining recent pull requests where someone has been granted `/allow` > +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search: > +is:pr is:open "/allow"]), in which case both the author and the person who > +granted the `/allow` can now `/allow` you, or by inquiring on the > +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode > +linking your pull request and asking for someone to `/allow` you. > + > If the CI fails, you can update your changes with `git rebase -i` and push your > branch again: >
On 25/10/19 05:51PM, Emily Shaffer wrote: > diff --git a/Documentation/MyFirstContribution.txt > b/Documentation/MyFirstContribution.txt > index b8ffeda07e..2de06de026 100644 > --- a/Documentation/MyFirstContribution.txt > +++ b/Documentation/MyFirstContribution.txt > @@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given > but you will not be able to `/submit` your changes until someone allows you to > use the tool. > > +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by > +either examining recent pull requests where someone has been granted `/allow` > +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search: > +is:pr is:open "/allow"]), in which case both the author and the person who > +granted the `/allow` can now `/allow` you, or by inquiring on the > +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode > +linking your pull request and asking for someone to `/allow` you. Nit: that's a lot to put in a single sentence. Maybe break it into parts like: NOTE: You can typically find someone who can `/allow` you on GitGitGadget by looking at recent pull requests where someone has been `/allow`ed. Both the author of that pull request and the person who granted the permission can now `/allow` you. You can also inquire on the IRC channel on Freenode linking your pull request and asking someone to `/allow` you. > + > If the CI fails, you can update your changes with `git rebase -i` and push your > branch again:
Hi Jonathan, On Fri, 25 Oct 2019, Jonathan Nieder wrote: > Emily Shaffer wrote: > > > GitGitGadget, a handy tool for converting pull requests against Git into > > Git-mailing-list-friendly-patch-emails, requires as anti-spam that all > > new users be "/allow"ed by an existing user once before it will do > > anything for that new user. While this tutorial explained that > > mechanism, it did not give much hint on how to go about finding someone > > to allow your new pull request. So, teach our new GitGitGadget user > > where to look for someone who can add their name to the list. > > > > The advice in this patch is based on the advice proposed for > > GitGitGadget: https://github.com/gitgitgadget/gitgitgadget/pull/138 > > > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com> > > --- > > Documentation/MyFirstContribution.txt | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> > > Though I'd appreciate an ack from a gitgitgadget specialist too, so > cc-ing Dscho. Seeing as the suggestions from gitgitgadget/gitgitgadget#138 partially came from me (and that I merged that PR after reviewing it), this comes very easily: Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Thanks, Dscho > > > diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt > > index b8ffeda07e..2de06de026 100644 > > --- a/Documentation/MyFirstContribution.txt > > +++ b/Documentation/MyFirstContribution.txt > > @@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given > > but you will not be able to `/submit` your changes until someone allows you to > > use the tool. > > > > +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by > > +either examining recent pull requests where someone has been granted `/allow` > > +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search: > > +is:pr is:open "/allow"]), in which case both the author and the person who > > +granted the `/allow` can now `/allow` you, or by inquiring on the > > +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode > > +linking your pull request and asking for someone to `/allow` you. > > + > > If the CI fails, you can update your changes with `git rebase -i` and push your > > branch again: > > >
diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt index b8ffeda07e..2de06de026 100644 --- a/Documentation/MyFirstContribution.txt +++ b/Documentation/MyFirstContribution.txt @@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given but you will not be able to `/submit` your changes until someone allows you to use the tool. +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by +either examining recent pull requests where someone has been granted `/allow` +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search: +is:pr is:open "/allow"]), in which case both the author and the person who +granted the `/allow` can now `/allow` you, or by inquiring on the +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode +linking your pull request and asking for someone to `/allow` you. + If the CI fails, you can update your changes with `git rebase -i` and push your branch again:
GitGitGadget, a handy tool for converting pull requests against Git into Git-mailing-list-friendly-patch-emails, requires as anti-spam that all new users be "/allow"ed by an existing user once before it will do anything for that new user. While this tutorial explained that mechanism, it did not give much hint on how to go about finding someone to allow your new pull request. So, teach our new GitGitGadget user where to look for someone who can add their name to the list. The advice in this patch is based on the advice proposed for GitGitGadget: https://github.com/gitgitgadget/gitgitgadget/pull/138 Signed-off-by: Emily Shaffer <emilyshaffer@google.com> --- Documentation/MyFirstContribution.txt | 8 ++++++++ 1 file changed, 8 insertions(+)