{"thread":{"id":"52124","subject":"[PATCH 0/3] some clarifications to MyFirstContribution","startedAt":"2019-10-26T00:54:04Z","lastAt":"2019-10-31T21:04:05Z","messageCount":20,"participants":["Emily Shaffer","Jonathan Nieder","SZEDER Gábor","Pratyush Yadav","Junio C Hamano","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"384892","messageId":"20191026005159.98405-1-emilyshaffer@google.com","threadId":"52124","inReplyTo":null,"subject":"[PATCH 0/3] some clarifications to MyFirstContribution","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-26T00:51:56Z","receivedAt":"2019-10-26T00:54:04Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Hi all,\n\nWith the wave of Outreachy participants (hello! welcome!) a few\nshortcomings in the MyFirstContribution tutorial have been noted; plus,\na comment from SZEDER (thanks!) sent along some weeks ago about a\nmissing step in the new command process.\n\n[1/3] Per SZEDER's comment, we should be adding `git psuh` to the list\n      of commands used by 'git help'.\n[2/3] Outreachy applicant Heba Waly indicated that the tutorial doesn't\n      cover dependencies needed to build Git. However, I don't have a\n      good handle on what's needed for platforms besides Linux, so I\n      really appreciate others suggesting dependency installation steps\n      for other platforms (even if it is a link to another guide).\n[3/3] Per some discussions in #git-devel this week, it's not apparent\n      who to ask for the /allow comment to tell GitGitGadget that you\n      can be trusted. So, add the same hint which is proposed to be\n      shown in GitGitGadget's welcome message.\n\nEmily Shaffer (3):\n  myfirstcontrib: add 'psuh' to command-list.txt\n  myfirstcontrib: add dependency installation step\n  myfirstcontrib: hint to find gitgitgadget allower\n\n Documentation/MyFirstContribution.txt | 57 +++++++++++++++++++++++++--\n 1 file changed, 54 insertions(+), 3 deletions(-)\n\n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"},{"id":"384893","messageId":"20191026005159.98405-2-emilyshaffer@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-1-emilyshaffer@google.com","subject":"[PATCH 1/3] myfirstcontrib: add 'psuh' to command-list.txt","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-26T00:51:57Z","receivedAt":"2019-10-26T00:54:04Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Users can discover commands and their brief usage by running 'git help\ngit' or 'git help -a'; both of these pages list all available commands\nbased on the contents of 'command-list.txt'. That means adding a new\ncommand there is an important part of the new command process, and\ntherefore belongs in the new command tutorial.\n\nTeach new users how to add their command, and include a brief overview\nof how to discover which attributes to place on the command in the list.\n\nSince 'git psuh' prints some workspace info, doesn't modify anything,\nand is targeted as a user-facing porcelain command, list it as a\n'mainporcelain' and 'info' command.\n\nAs the usage string is required to generate this documentation, don't\nadd the command to the list until after the usage string is added to the\ntutorial.\n\nSigned-off-by: Emily Shaffer <emilyshaffer@google.com>\n---\n Documentation/MyFirstContribution.txt | 22 ++++++++++++++++++++++\n 1 file changed, 22 insertions(+)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 5e9b808f5f..12b7256454 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -534,6 +534,28 @@ you want to pass as a parameter something which would usually be interpreted as\n a flag.) `parse_options()` will terminate parsing when it reaches `--` and give\n you the rest of the options afterwards, untouched.\n \n+Now that you have a usage hint, you can teach Git how to show it in the general\n+command list shown by `git help git` or `git help -a`, which is generated from\n+`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n+line above it in alphabetical order. Now, we can add some attributes about the\n+command which impacts where it shows up in the aforementioned help commands. The\n+top of `command-list.txt` shares some information about what each attribute\n+means; in those help pages, the commands are sorted according to these\n+attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n+\"mainporcelain\". For \"mainporcelain\" commands, the comments at the top of\n+`command-list.txt` indicate we can also optionally add an attribute from another\n+list; since `git psuh` shows some information about the user's workspace but\n+doesn't modify anything, let's mark it as \"info\". Make sure to keep your\n+attributes in the same style as the rest of `command-list.txt` using spaces to\n+align and delineate them:\n+\n+----\n+git-prune-packed                        plumbingmanipulators\n+git-psuh                                mainporcelain\t\tinfo\n+git-pull                                mainporcelain           remote\n+git-push                                mainporcelain           remote\n+----\n+\n Build again. Now, when you run with `-h`, you should see your usage printed and\n your command terminated before anything else interesting happens. Great!\n \n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"},{"id":"384894","messageId":"20191026005159.98405-3-emilyshaffer@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-1-emilyshaffer@google.com","subject":"[PATCH 2/3] myfirstcontrib: add dependency installation step","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-26T00:51:58Z","receivedAt":"2019-10-26T00:54:17Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Indicate that the user needs some dependencies before the build will run\nhappily on their machine; this dependency list doesn't seem to be made\nclear anywhere else in the project documentation. Then, so the user can\nbe certain any build failures are due to their code and not their\nenvironment, perform a build on a clean checkout of 'master'. Also, move\nthe note about build parallelization up here, so that it appears next to\nthe very first build invocation in the tutorial.\n\nSigned-off-by: Emily Shaffer <emilyshaffer@google.com>\n---\n Documentation/MyFirstContribution.txt | 27 ++++++++++++++++++++++++---\n 1 file changed, 24 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 12b7256454..b8ffeda07e 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -38,6 +38,30 @@ $ git clone https://github.com/git/git git\n $ cd git\n ----\n \n+[[dependencies]]\n+=== Installing Dependencies\n+\n+To build Git from source, you need to have a handful of dependencies installed\n+on your system. For a hint of what's needed, you can take a look at\n+`ci/install-dependencies.sh`.\n+\n+To install the dependencies needed for a basic build on Linux, run something\n+like this (or replace `apt` with your distribution's package manager of choice):\n+\n+----\n+# apt install libssl-dev zlib1g-dev libcurl4-gnutls-dev libexpat1-dev\n+----\n+\n+Make sure that your environment has everything you need by building your brand\n+new clone of Git from the above step:\n+\n+----\n+$ make\n+----\n+\n+NOTE: The Git build is parallelizable. `-j#` is not included above but you can\n+use it as you prefer, here and elsewhere.\n+\n [[identify-problem]]\n === Identify Problem to Solve\n \n@@ -138,9 +162,6 @@ NOTE: When you are developing the Git project, it's preferred that you use the\n `DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn\n it off, but it's a good idea to mention the problem to the mailing list.\n \n-NOTE: The Git build is parallelizable. `-j#` is not included above but you can\n-use it as you prefer, here and elsewhere.\n-\n Great, now your new command builds happily on its own. But nobody invokes it.\n Let's change that.\n \n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"},{"id":"384895","messageId":"20191026005159.98405-4-emilyshaffer@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-1-emilyshaffer@google.com","subject":"[PATCH 3/3] myfirstcontrib: hint to find gitgitgadget allower","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-26T00:51:59Z","receivedAt":"2019-10-26T00:54:17Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"GitGitGadget, a handy tool for converting pull requests against Git into\nGit-mailing-list-friendly-patch-emails, requires as anti-spam that all\nnew users be \"/allow\"ed by an existing user once before it will do\nanything for that new user. While this tutorial explained that\nmechanism, it did not give much hint on how to go about finding someone\nto allow your new pull request. So, teach our new GitGitGadget user\nwhere to look for someone who can add their name to the list.\n\nThe advice in this patch is based on the advice proposed for\nGitGitGadget: https://github.com/gitgitgadget/gitgitgadget/pull/138\n\nSigned-off-by: Emily Shaffer <emilyshaffer@google.com>\n---\n Documentation/MyFirstContribution.txt | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex b8ffeda07e..2de06de026 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given\n but you will not be able to `/submit` your changes until someone allows you to\n use the tool.\n \n+NOTE: You can typically find someone who can `/allow` you on GitGitGadget by\n+either examining recent pull requests where someone has been granted `/allow`\n+(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:\n+is:pr is:open \"/allow\"]), in which case both the author and the person who\n+granted the `/allow` can now `/allow` you, or by inquiring on the\n+https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode\n+linking your pull request and asking for someone to `/allow` you.\n+\n If the CI fails, you can update your changes with `git rebase -i` and push your\n branch again:\n \n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"},{"id":"384896","messageId":"20191026010857.GA39574@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-2-emilyshaffer@google.com","subject":"Re: [PATCH 1/3] myfirstcontrib: add 'psuh' to command-list.txt","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-10-26T01:08:57Z","receivedAt":"2019-10-26T01:09:01Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nEmily Shaffer wrote:\n\n> Users can discover commands and their brief usage by running 'git help\n> git' or 'git help -a'; both of these pages list all available commands\n> based on the contents of 'command-list.txt'. That means adding a new\n> command there is an important part of the new command process, and\n> therefore belongs in the new command tutorial.\n\nMakes sense.\n\nNot about this patch: is there a way to detect this automatically?\nE.g. if a command in git.c::commands doesn't appear in\ncommand-list.txt, could we make Git fail \"make test\"?\n\n[...]\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -534,6 +534,28 @@ you want to pass as a parameter something which would usually be interpreted as\n>  a flag.) `parse_options()` will terminate parsing when it reaches `--` and give\n>  you the rest of the options afterwards, untouched.\n>  \n> +Now that you have a usage hint, you can teach Git how to show it in the general\n> +command list shown by `git help git` or `git help -a`, which is generated from\n> +`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n> +line above it in alphabetical order. Now, we can add some attributes about the\n> +command which impacts where it shows up in the aforementioned help commands. The\n\nnit: s/impacts/impact/, to agree with \"attributes\"\n\n> +top of `command-list.txt` shares some information about what each attribute\n> +means; in those help pages, the commands are sorted according to these\n> +attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n                                             ^^^^^^^^^\n\noptional: This might be an unfamiliar term to people not thinking of the\nplumbing fixture / chrome analogy.  Is there anything we should do to\nhelp them understand what's going on?\n\nE.g. \"git help glossary\" says\n\n\tPorcelains expose more of a SCM interface than the plumbing.\n\n> +\"mainporcelain\". For \"mainporcelain\" commands, the comments at the top of\n> +`command-list.txt` indicate we can also optionally add an attribute from another\n> +list; since `git psuh` shows some information about the user's workspace but\n> +doesn't modify anything, let's mark it as \"info\". Make sure to keep your\n> +attributes in the same style as the rest of `command-list.txt` using spaces to\n> +align and delineate them:\n> +\n> +----\n> +git-prune-packed                        plumbingmanipulators\n> +git-psuh                                mainporcelain\t\tinfo\n\ntabs snuck in.\n\n> +git-pull                                mainporcelain           remote\n> +git-push                                mainporcelain           remote\n> +----\n> +\n\nThe rest looks good.\n\nThanks,\nJonathan\n"},{"id":"384897","messageId":"20191026011250.GB39574@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-3-emilyshaffer@google.com","subject":"Re: [PATCH 2/3] myfirstcontrib: add dependency installation step","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-10-26T01:12:51Z","receivedAt":"2019-10-26T01:12:55Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nEmily Shaffer wrote:\n\n> Indicate that the user needs some dependencies before the build will run\n> happily on their machine; this dependency list doesn't seem to be made\n> clear anywhere else in the project documentation.\n\nIn theory, this info should be in INSTALL.  I wouldn't be surprised if\nit's missing some info, though.\n\n[...]\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -38,6 +38,30 @@ $ git clone https://github.com/git/git git\n>  $ cd git\n>  ----\n>  \n> +[[dependencies]]\n> +=== Installing Dependencies\n> +\n> +To build Git from source, you need to have a handful of dependencies installed\n> +on your system. For a hint of what's needed, you can take a look at\n> +`ci/install-dependencies.sh`.\n> +\n> +To install the dependencies needed for a basic build on Linux, run something\n> +like this (or replace `apt` with your distribution's package manager of choice):\n\npedantic nit: s/or replace/replacing/ (\"or\" would mean rpm is an\nalternative to what came before, but \"something like\" in the phrase\nbefore has rpm already included)\n\n> +\n> +----\n> +# apt install libssl-dev zlib1g-dev libcurl4-gnutls-dev libexpat1-dev\n\nPerhaps build-essential, too, in case they're using a system not set up\nfor development.\n\n> +----\n> +\n> +Make sure that your environment has everything you need by building your brand\n> +new clone of Git from the above step:\n> +\n> +----\n> +$ make\n> +----\n> +\n> +NOTE: The Git build is parallelizable. `-j#` is not included above but you can\n> +use it as you prefer, here and elsewhere.\n> +\n>  [[identify-problem]]\n>  === Identify Problem to Solve\n>  \n> @@ -138,9 +162,6 @@ NOTE: When you are developing the Git project, it's preferred that you use the\n>  `DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn\n>  it off, but it's a good idea to mention the problem to the mailing list.\n>  \n> -NOTE: The Git build is parallelizable. `-j#` is not included above but you can\n> -use it as you prefer, here and elsewhere.\n> -\n>  Great, now your new command builds happily on its own. But nobody invokes it.\n>  Let's change that.\n\nWith whatever subset of the changes above make sense,\nReviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nThanks.\n"},{"id":"384898","messageId":"20191026011459.GC39574@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-4-emilyshaffer@google.com","subject":"Re: [PATCH 3/3] myfirstcontrib: hint to find gitgitgadget allower","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-10-26T01:15:00Z","receivedAt":"2019-10-26T01:15:04Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Emily Shaffer wrote:\n\n> GitGitGadget, a handy tool for converting pull requests against Git into\n> Git-mailing-list-friendly-patch-emails, requires as anti-spam that all\n> new users be \"/allow\"ed by an existing user once before it will do\n> anything for that new user. While this tutorial explained that\n> mechanism, it did not give much hint on how to go about finding someone\n> to allow your new pull request. So, teach our new GitGitGadget user\n> where to look for someone who can add their name to the list.\n>\n> The advice in this patch is based on the advice proposed for\n> GitGitGadget: https://github.com/gitgitgadget/gitgitgadget/pull/138\n>\n> Signed-off-by: Emily Shaffer <emilyshaffer@google.com>\n> ---\n>  Documentation/MyFirstContribution.txt | 8 ++++++++\n>  1 file changed, 8 insertions(+)\n\nReviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nThough I'd appreciate an ack from a gitgitgadget specialist too, so\ncc-ing Dscho.\n\n> diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\n> index b8ffeda07e..2de06de026 100644\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given\n>  but you will not be able to `/submit` your changes until someone allows you to\n>  use the tool.\n>  \n> +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by\n> +either examining recent pull requests where someone has been granted `/allow`\n> +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:\n> +is:pr is:open \"/allow\"]), in which case both the author and the person who\n> +granted the `/allow` can now `/allow` you, or by inquiring on the\n> +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode\n> +linking your pull request and asking for someone to `/allow` you.\n> +\n>  If the CI fails, you can update your changes with `git rebase -i` and push your\n>  branch again:\n>  \n"},{"id":"384899","messageId":"20191026011715.GD39574@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-1-emilyshaffer@google.com","subject":"Re: [PATCH 0/3] some clarifications to MyFirstContribution","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-10-26T01:17:15Z","receivedAt":"2019-10-26T01:17:19Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Emily Shaffer wrote:\n\n> [1/3] Per SZEDER's comment, we should be adding `git psuh` to the list\n>       of commands used by 'git help'.\n> [2/3] Outreachy applicant Heba Waly indicated that the tutorial doesn't\n>       cover dependencies needed to build Git.\n\nOh!  It's also a good idea to give these people credit for their\ncontribution, via a Reported-by in the commit message.\n\nSorry I missed it before (I tend to read the patches first and cover\nletter last, which is good for ensuring the commit messages are self\ncontained enough to be helpful when the patch gets dug up in history\nlater, but not so good for noticing this kind of thing).\n\nThanks,\nJonathan\n"},{"id":"384906","messageId":"20191026080057.GP4348@szeder.dev","threadId":"52124","inReplyTo":"20191026010857.GA39574@google.com","subject":"Re: [PATCH 1/3] myfirstcontrib: add 'psuh' to command-list.txt","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-10-26T08:00:57Z","receivedAt":"2019-10-26T08:01:05Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Oct 25, 2019 at 06:08:57PM -0700, Jonathan Nieder wrote:\n> > Users can discover commands and their brief usage by running 'git help\n> > git' or 'git help -a'; both of these pages list all available commands\n> > based on the contents of 'command-list.txt'. That means adding a new\n> > command there is an important part of the new command process, and\n> > therefore belongs in the new command tutorial.\n> \n> Makes sense.\n> \n> Not about this patch: is there a way to detect this automatically?\n> E.g. if a command in git.c::commands doesn't appear in\n> command-list.txt, could we make Git fail \"make test\"?\n\nWe almost detect this already:\n\n  $ sed -i -e '/^git-bisect/d' command-list.txt \n  $ make check-docs\n  make -C Documentation lint-docs\n  make[1]: Entering directory '/home/szeder/src/git/Documentation'\n      GEN cmd-list.made\n      GEN doc.dep\n  make[2]: Entering directory '/home/szeder/src/git'\n  make[2]: 'GIT-VERSION-FILE' is up to date.\n  make[2]: Leaving directory '/home/szeder/src/git'\n  make[2]: Entering directory '/home/szeder/src/git'\n  make[2]: 'GIT-VERSION-FILE' is up to date.\n  make[2]: Leaving directory '/home/szeder/src/git'\n      LINT lint-docs\n  make[1]: Leaving directory '/home/szeder/src/git/Documentation'\n  no link: git-bisect\n  $ echo $?\n  0\n\nSee that last \"no link: git-bisect\" line?  That's what happened to\ncatch my eyes when Derrick forgot to add his new 'sparse-checkout'\nbuiltin to 'command-list.txt'.  I still haven't looked up what that\n'no link' is supposed to mean, but if it were an error, then we would\nhave surely detected the missing entry in 'command-list.txt' in out CI\nbuilds.\n\nAnother possibility would be to auto-generate that long list of\n'cmd_foo()' function declaration in 'builtin.h' from\n'command-list.txt', by adding a 'builtin' attribute to mark builtin\ncommands.\n\n"},{"id":"384926","messageId":"20191027013900.m7t4u6lo4tc4cdqz@yadavpratyush.com","threadId":"52124","inReplyTo":"20191026005159.98405-4-emilyshaffer@google.com","subject":"Re: [PATCH 3/3] myfirstcontrib: hint to find gitgitgadget allower","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-27T01:39:01Z","receivedAt":"2019-10-27T01:39:11Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 25/10/19 05:51PM, Emily Shaffer wrote:\n> diff --git a/Documentation/MyFirstContribution.txt \n> b/Documentation/MyFirstContribution.txt\n> index b8ffeda07e..2de06de026 100644\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given\n>  but you will not be able to `/submit` your changes until someone allows you to\n>  use the tool.\n>  \n> +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by\n> +either examining recent pull requests where someone has been granted `/allow`\n> +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:\n> +is:pr is:open \"/allow\"]), in which case both the author and the person who\n> +granted the `/allow` can now `/allow` you, or by inquiring on the\n> +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode\n> +linking your pull request and asking for someone to `/allow` you.\n\nNit: that's a lot to put in a single sentence. Maybe break it into parts \nlike:\n\n  NOTE: You can typically find someone who can `/allow` you on \n  GitGitGadget by looking at recent pull requests where someone has been \n  `/allow`ed. Both the author of that pull request and the person who \n  granted the permission can now `/allow` you. You can also inquire on \n  the IRC channel on Freenode linking your pull request and asking \n  someone to `/allow` you.\n\n> +\n>  If the CI fails, you can update your changes with `git rebase -i` and push your\n>  branch again:\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384955","messageId":"xmqqmudlbr1s.fsf@gitster-ct.c.googlers.com","threadId":"52124","inReplyTo":"20191026080057.GP4348@szeder.dev","subject":"Re: [PATCH 1/3] myfirstcontrib: add 'psuh' to command-list.txt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-10-28T01:24:31Z","receivedAt":"2019-10-28T01:24:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor <szeder.dev@gmail.com> writes:\n\n> See that last \"no link: git-bisect\" line?  That's what happened to\n> catch my eyes when Derrick forgot to add his new 'sparse-checkout'\n> builtin to 'command-list.txt'.  I still haven't looked up what that\n> 'no link' is supposed to mean, but if it were an error, then we would\n\nBuild procedure for the Documentation uses ../command-list.txt as\nits input to produce cmds-<class>.txt files, that are included in\ngit.txt (hence resulting git.1 and git.html).  While it works, it\ntries to make sure that a command that has its own documentation\npage at Documentation/git-<command>.txt is listed; otherwise we have\na page for <command> to which there is no link from git.{1,html}.\n\nI think \"make check-builtins\" might also want to sanity check\ncommand-list.txt.\n\n\n"},{"id":"384956","messageId":"xmqqimo9bqwy.fsf@gitster-ct.c.googlers.com","threadId":"52124","inReplyTo":"20191026011250.GB39574@google.com","subject":"Re: [PATCH 2/3] myfirstcontrib: add dependency installation step","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-10-28T01:27:25Z","receivedAt":"2019-10-28T01:27:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Hi,\n>\n> Emily Shaffer wrote:\n>\n>> Indicate that the user needs some dependencies before the build will run\n>> happily on their machine; this dependency list doesn't seem to be made\n>> clear anywhere else in the project documentation.\n>\n> In theory, this info should be in INSTALL.  I wouldn't be surprised if\n> it's missing some info, though.\n>\n> [...]\n>> --- a/Documentation/MyFirstContribution.txt\n>> +++ b/Documentation/MyFirstContribution.txt\n>> @@ -38,6 +38,30 @@ $ git clone https://github.com/git/git git\n>>  $ cd git\n>>  ----\n>>  \n>> +[[dependencies]]\n>> +=== Installing Dependencies\n>> +\n>> +To build Git from source, you need to have a handful of dependencies installed\n>> +on your system. For a hint of what's needed, you can take a look at\n>> +`ci/install-dependencies.sh`.\n>> +\n>> +To install the dependencies needed for a basic build on Linux, run something\n>> +like this (or replace `apt` with your distribution's package manager of choice):\n>\n> pedantic nit: s/or replace/replacing/ (\"or\" would mean rpm is an\n> alternative to what came before, but \"something like\" in the phrase\n> before has rpm already included)\n\nThis section, as you hinted at the beginning, should be a single\nsentence, i.e. just \"follow INSTALL\".  Any clarifications should \nbe made as a patch to the INSTALL file.\n\nThanks.\n"},{"id":"384978","messageId":"20191028112530.GQ4348@szeder.dev","threadId":"52124","inReplyTo":"xmqqmudlbr1s.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/3] myfirstcontrib: add 'psuh' to command-list.txt","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-10-28T11:25:30Z","receivedAt":"2019-10-28T11:25:38Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Oct 28, 2019 at 10:24:31AM +0900, Junio C Hamano wrote:\n> SZEDER Gábor <szeder.dev@gmail.com> writes:\n> \n> > See that last \"no link: git-bisect\" line?  That's what happened to\n> > catch my eyes when Derrick forgot to add his new 'sparse-checkout'\n> > builtin to 'command-list.txt'.  I still haven't looked up what that\n> > 'no link' is supposed to mean, but if it were an error, then we would\n> \n> Build procedure for the Documentation uses ../command-list.txt as\n> its input to produce cmds-<class>.txt files, that are included in\n> git.txt (hence resulting git.1 and git.html).  While it works, it\n> tries to make sure that a command that has its own documentation\n> page at Documentation/git-<command>.txt is listed; otherwise we have\n> a page for <command> to which there is no link from git.{1,html}.\n\nOh, then it doesn't quite do what I thought it does.\n\n> I think \"make check-builtins\" might also want to sanity check\n> command-list.txt.\n\nI haven't noticed that we have something like that.  FWIW, our\ndocumentation CI job runs it already.\n\nAnd indeed it can be easily extended to check 'command-list.txt' as\nwell, but then it will find some other builtins not included in\n'command-list.txt', namely:\n\n  bisect--helper env--helper fsck-objects init-db merge-ours\n  merge-recursive merge-subtree remote-ext remote-fd submodule--helper\n\nI think it makes sense not to include the '*--helper' commands, or\n'fsck-objects' and 'init-db', but I'm not sure about the others.\n\nOTOH, it won't help if we add a new git-foo script and forgot to\ninclude it in 'command-list.txt'.\n\n"},{"id":"385110","messageId":"nycvar.QRO.7.76.6.1910292136080.46@tvgsbejvaqbjf.bet","threadId":"52124","inReplyTo":"20191026080057.GP4348@szeder.dev","subject":"Re: [PATCH 1/3] myfirstcontrib: add 'psuh' to command-list.txt","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-10-29T20:39:20Z","receivedAt":"2019-10-29T20:39:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Sat, 26 Oct 2019, SZEDER Gábor wrote:\n\n> On Fri, Oct 25, 2019 at 06:08:57PM -0700, Jonathan Nieder wrote:\n> > > Users can discover commands and their brief usage by running 'git help\n> > > git' or 'git help -a'; both of these pages list all available commands\n> > > based on the contents of 'command-list.txt'. That means adding a new\n> > > command there is an important part of the new command process, and\n> > > therefore belongs in the new command tutorial.\n> >\n> > Makes sense.\n> >\n> > Not about this patch: is there a way to detect this automatically?\n> > E.g. if a command in git.c::commands doesn't appear in\n> > command-list.txt, could we make Git fail \"make test\"?\n>\n> We almost detect this already:\n>\n>   $ sed -i -e '/^git-bisect/d' command-list.txt\n>   $ make check-docs\n>   make -C Documentation lint-docs\n>   make[1]: Entering directory '/home/szeder/src/git/Documentation'\n>       GEN cmd-list.made\n>       GEN doc.dep\n>   make[2]: Entering directory '/home/szeder/src/git'\n>   make[2]: 'GIT-VERSION-FILE' is up to date.\n>   make[2]: Leaving directory '/home/szeder/src/git'\n>   make[2]: Entering directory '/home/szeder/src/git'\n>   make[2]: 'GIT-VERSION-FILE' is up to date.\n>   make[2]: Leaving directory '/home/szeder/src/git'\n>       LINT lint-docs\n>   make[1]: Leaving directory '/home/szeder/src/git/Documentation'\n>   no link: git-bisect\n>   $ echo $?\n>   0\n>\n> See that last \"no link: git-bisect\" line?  That's what happened to\n> catch my eyes when Derrick forgot to add his new 'sparse-checkout'\n> builtin to 'command-list.txt'.  I still haven't looked up what that\n> 'no link' is supposed to mean, but if it were an error, then we would\n> have surely detected the missing entry in 'command-list.txt' in out CI\n> builds.\n\nFWIW I think the only reason that this is not an error in `check-docs`\n(which _is_ run by our CI/PR builds, in the `Documentation` job) is that\nit used to be buggy.\n\nHowever, I think I managed to address the remaining issues in\n`js/misc-doc-fixes` (and maybe there were a couple spill-overs into\n`js/check-docs-exe`).\n\nIn short: I think we can make this type of issue trigger an error in\n`check-docs` now (as in: non-zero exit code).\n\nCiao,\nDscho\n\n>\n> Another possibility would be to auto-generate that long list of\n> 'cmd_foo()' function declaration in 'builtin.h' from\n> 'command-list.txt', by adding a 'builtin' attribute to mark builtin\n> commands.\n>\n>\n"},{"id":"385112","messageId":"nycvar.QRO.7.76.6.1910292141340.46@tvgsbejvaqbjf.bet","threadId":"52124","inReplyTo":"20191026011459.GC39574@google.com","subject":"Re: [PATCH 3/3] myfirstcontrib: hint to find gitgitgadget allower","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-10-29T20:43:16Z","receivedAt":"2019-10-29T20:43:36Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jonathan,\n\nOn Fri, 25 Oct 2019, Jonathan Nieder wrote:\n\n> Emily Shaffer wrote:\n>\n> > GitGitGadget, a handy tool for converting pull requests against Git into\n> > Git-mailing-list-friendly-patch-emails, requires as anti-spam that all\n> > new users be \"/allow\"ed by an existing user once before it will do\n> > anything for that new user. While this tutorial explained that\n> > mechanism, it did not give much hint on how to go about finding someone\n> > to allow your new pull request. So, teach our new GitGitGadget user\n> > where to look for someone who can add their name to the list.\n> >\n> > The advice in this patch is based on the advice proposed for\n> > GitGitGadget: https://github.com/gitgitgadget/gitgitgadget/pull/138\n> >\n> > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>\n> > ---\n> >  Documentation/MyFirstContribution.txt | 8 ++++++++\n> >  1 file changed, 8 insertions(+)\n>\n> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n>\n> Though I'd appreciate an ack from a gitgitgadget specialist too, so\n> cc-ing Dscho.\n\nSeeing as the suggestions from gitgitgadget/gitgitgadget#138 partially\ncame from me (and that I merged that PR after reviewing it), this comes\nvery easily:\n\nAcked-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nThanks,\nDscho\n>\n> > diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\n> > index b8ffeda07e..2de06de026 100644\n> > --- a/Documentation/MyFirstContribution.txt\n> > +++ b/Documentation/MyFirstContribution.txt\n> > @@ -789,6 +789,14 @@ will automatically run your PRs through the CI even without the permission given\n> >  but you will not be able to `/submit` your changes until someone allows you to\n> >  use the tool.\n> >\n> > +NOTE: You can typically find someone who can `/allow` you on GitGitGadget by\n> > +either examining recent pull requests where someone has been granted `/allow`\n> > +(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:\n> > +is:pr is:open \"/allow\"]), in which case both the author and the person who\n> > +granted the `/allow` can now `/allow` you, or by inquiring on the\n> > +https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode\n> > +linking your pull request and asking for someone to `/allow` you.\n> > +\n> >  If the CI fails, you can update your changes with `git rebase -i` and push your\n> >  branch again:\n> >\n>\n"},{"id":"385242","messageId":"20191031205805.GC229589@google.com","threadId":"52124","inReplyTo":"xmqqimo9bqwy.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 2/3] myfirstcontrib: add dependency installation step","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-31T20:58:05Z","receivedAt":"2019-10-31T20:58:12Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Mon, Oct 28, 2019 at 10:27:25AM +0900, Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n> \n> > Hi,\n> >\n> > Emily Shaffer wrote:\n> >\n> >> Indicate that the user needs some dependencies before the build will run\n> >> happily on their machine; this dependency list doesn't seem to be made\n> >> clear anywhere else in the project documentation.\n> >\n> > In theory, this info should be in INSTALL.  I wouldn't be surprised if\n> > it's missing some info, though.\n> >\n> > [...]\n> >> --- a/Documentation/MyFirstContribution.txt\n> >> +++ b/Documentation/MyFirstContribution.txt\n> >> @@ -38,6 +38,30 @@ $ git clone https://github.com/git/git git\n> >>  $ cd git\n> >>  ----\n> >>  \n> >> +[[dependencies]]\n> >> +=== Installing Dependencies\n> >> +\n> >> +To build Git from source, you need to have a handful of dependencies installed\n> >> +on your system. For a hint of what's needed, you can take a look at\n> >> +`ci/install-dependencies.sh`.\n> >> +\n> >> +To install the dependencies needed for a basic build on Linux, run something\n> >> +like this (or replace `apt` with your distribution's package manager of choice):\n> >\n> > pedantic nit: s/or replace/replacing/ (\"or\" would mean rpm is an\n> > alternative to what came before, but \"something like\" in the phrase\n> > before has rpm already included)\n> \n> This section, as you hinted at the beginning, should be a single\n> sentence, i.e. just \"follow INSTALL\".  Any clarifications should \n> be made as a patch to the INSTALL file.\n\nThanks. I ended up with a little over one sentence; I don't like that a\nnewbie following INSTALL file would end up with their locally-built Git\ninstalled (and they may only be interested in a one-off contribution,\nand never fetch again, or something) so I tried to highlight the\ndependencies portion of INSTALL:\n\n  To build Git from source, you need to have a handful of dependencies installed\n  on your system. For a hint of what's needed, you can take a look at\n  `INSTALL`, paying close attention to the section about Git's dependencies on\n  external programs and libraries. That document mentions a way to \"test-drive\"\n  our freshly built Git without installing; that's the method we'll be using in\n  this tutorial.\n\n  Make sure that your environment has everything you need by building your brand\n  new clone of Git from the above step:\n\n - Emily\n"},{"id":"385243","messageId":"20191031210338.152529-1-emilyshaffer@google.com","threadId":"52124","inReplyTo":"20191026005159.98405-1-emilyshaffer@google.com","subject":"[PATCH v2 0/3] some clarifications to MyFirstContribution","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-31T21:03:35Z","receivedAt":"2019-10-31T21:03:58Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"With adjustments to install step based on email comments, plus\nReported-by in command-list and install step patches.\n\n - Emily\n\nEmily Shaffer (3):\n  myfirstcontrib: add 'psuh' to command-list.txt\n  myfirstcontrib: add dependency installation step\n  myfirstcontrib: hint to find gitgitgadget allower\n\n Documentation/MyFirstContribution.txt | 53 +++++++++++++++++++++++++--\n 1 file changed, 50 insertions(+), 3 deletions(-)\n\n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"},{"id":"385244","messageId":"20191031210338.152529-2-emilyshaffer@google.com","threadId":"52124","inReplyTo":"20191031210338.152529-1-emilyshaffer@google.com","subject":"[PATCH v2 1/3] myfirstcontrib: add 'psuh' to command-list.txt","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-31T21:03:36Z","receivedAt":"2019-10-31T21:03:59Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Users can discover commands and their brief usage by running 'git help\ngit' or 'git help -a'; both of these pages list all available commands\nbased on the contents of 'command-list.txt'. That means adding a new\ncommand there is an important part of the new command process, and\ntherefore belongs in the new command tutorial.\n\nTeach new users how to add their command, and include a brief overview\nof how to discover which attributes to place on the command in the list.\n\nSince 'git psuh' prints some workspace info, doesn't modify anything,\nand is targeted as a user-facing porcelain command, list it as a\n'mainporcelain' and 'info' command.\n\nAs the usage string is required to generate this documentation, don't\nadd the command to the list until after the usage string is added to the\ntutorial.\n\nReported-by: SZEDER Gábor <szeder.dev@gmail.com>\nSigned-off-by: Emily Shaffer <emilyshaffer@google.com>\n---\n Documentation/MyFirstContribution.txt | 22 ++++++++++++++++++++++\n 1 file changed, 22 insertions(+)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 5e9b808f5f..12b7256454 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -534,6 +534,28 @@ you want to pass as a parameter something which would usually be interpreted as\n a flag.) `parse_options()` will terminate parsing when it reaches `--` and give\n you the rest of the options afterwards, untouched.\n \n+Now that you have a usage hint, you can teach Git how to show it in the general\n+command list shown by `git help git` or `git help -a`, which is generated from\n+`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'\n+line above it in alphabetical order. Now, we can add some attributes about the\n+command which impacts where it shows up in the aforementioned help commands. The\n+top of `command-list.txt` shares some information about what each attribute\n+means; in those help pages, the commands are sorted according to these\n+attributes. `git psuh` is user-facing, or porcelain - so we will mark it as\n+\"mainporcelain\". For \"mainporcelain\" commands, the comments at the top of\n+`command-list.txt` indicate we can also optionally add an attribute from another\n+list; since `git psuh` shows some information about the user's workspace but\n+doesn't modify anything, let's mark it as \"info\". Make sure to keep your\n+attributes in the same style as the rest of `command-list.txt` using spaces to\n+align and delineate them:\n+\n+----\n+git-prune-packed                        plumbingmanipulators\n+git-psuh                                mainporcelain\t\tinfo\n+git-pull                                mainporcelain           remote\n+git-push                                mainporcelain           remote\n+----\n+\n Build again. Now, when you run with `-h`, you should see your usage printed and\n your command terminated before anything else interesting happens. Great!\n \n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"},{"id":"385245","messageId":"20191031210338.152529-3-emilyshaffer@google.com","threadId":"52124","inReplyTo":"20191031210338.152529-1-emilyshaffer@google.com","subject":"[PATCH v2 2/3] myfirstcontrib: add dependency installation step","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-31T21:03:37Z","receivedAt":"2019-10-31T21:04:02Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Indicate that the user needs some dependencies before the build will run\nhappily on their machine; this dependency list doesn't seem to be made\nclear anywhere else in the project documentation. Then, so the user can\nbe certain any build failures are due to their code and not their\nenvironment, perform a build on a clean checkout of 'master'. Also, move\nthe note about build parallelization up here, so that it appears next to\nthe very first build invocation in the tutorial.\n\nReported-by: Heba Waly <heba.waly@gmail.com>\nSigned-off-by: Emily Shaffer <emilyshaffer@google.com>\n---\n Documentation/MyFirstContribution.txt | 23 ++++++++++++++++++++---\n 1 file changed, 20 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 12b7256454..5ce94e077c 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -38,6 +38,26 @@ $ git clone https://github.com/git/git git\n $ cd git\n ----\n \n+[[dependencies]]\n+=== Installing Dependencies\n+\n+To build Git from source, you need to have a handful of dependencies installed\n+on your system. For a hint of what's needed, you can take a look at\n+`INSTALL`, paying close attention to the section about Git's dependencies on\n+external programs and libraries. That document mentions a way to \"test-drive\"\n+our freshly built Git without installing; that's the method we'll be using in\n+this tutorial.\n+\n+Make sure that your environment has everything you need by building your brand\n+new clone of Git from the above step:\n+\n+----\n+$ make\n+----\n+\n+NOTE: The Git build is parallelizable. `-j#` is not included above but you can\n+use it as you prefer, here and elsewhere.\n+\n [[identify-problem]]\n === Identify Problem to Solve\n \n@@ -138,9 +158,6 @@ NOTE: When you are developing the Git project, it's preferred that you use the\n `DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn\n it off, but it's a good idea to mention the problem to the mailing list.\n \n-NOTE: The Git build is parallelizable. `-j#` is not included above but you can\n-use it as you prefer, here and elsewhere.\n-\n Great, now your new command builds happily on its own. But nobody invokes it.\n Let's change that.\n \n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"},{"id":"385246","messageId":"20191031210338.152529-4-emilyshaffer@google.com","threadId":"52124","inReplyTo":"20191031210338.152529-1-emilyshaffer@google.com","subject":"[PATCH v2 3/3] myfirstcontrib: hint to find gitgitgadget allower","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-10-31T21:03:38Z","receivedAt":"2019-10-31T21:04:05Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"GitGitGadget, a handy tool for converting pull requests against Git into\nGit-mailing-list-friendly-patch-emails, requires as anti-spam that all\nnew users be \"/allow\"ed by an existing user once before it will do\nanything for that new user. While this tutorial explained that\nmechanism, it did not give much hint on how to go about finding someone\nto allow your new pull request. So, teach our new GitGitGadget user\nwhere to look for someone who can add their name to the list.\n\nThe advice in this patch is based on the advice proposed for\nGitGitGadget: https://github.com/gitgitgadget/gitgitgadget/pull/138\n\nSigned-off-by: Emily Shaffer <emilyshaffer@google.com>\n---\n Documentation/MyFirstContribution.txt | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 5ce94e077c..b55837e646 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -785,6 +785,14 @@ will automatically run your PRs through the CI even without the permission given\n but you will not be able to `/submit` your changes until someone allows you to\n use the tool.\n \n+NOTE: You can typically find someone who can `/allow` you on GitGitGadget by\n+either examining recent pull requests where someone has been granted `/allow`\n+(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:\n+is:pr is:open \"/allow\"]), in which case both the author and the person who\n+granted the `/allow` can now `/allow` you, or by inquiring on the\n+https://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode\n+linking your pull request and asking for someone to `/allow` you.\n+\n If the CI fails, you can update your changes with `git rebase -i` and push your\n branch again:\n \n-- \n2.24.0.rc0.303.g954a862665-goog\n\n"}]}