On Fri, Jan 17, 2020 at 15:44 ToddAndMargo via perl6-users < perl6-users@perl.org> wrote:
> On 2020-01-17 12:20, Trey Harris wrote: > > If the issue is that you aren’t comfortable enough with Git¹, I assume > > as part of the basic toolkit of a sysadmin you know how to generate a > > unified diff patchfile (with `diff -ruN` or equivalent)? > > > > If so, if you generate one and upload it attached to a GitHub issue, we > > can figure out how to turn it into a PR rather trivially (and if I’m the > > first to pick it up, I’ll include step-by-step instructions on how to do > > it as a Git PR in the future). > > Now I am confused. Exactly what is going on with a PR? A “PR” is a “pull request”—in Git terminology, a request to apply a patch. It formalizes and standardizes the process that existed on many FOSS project dev mailing lists (most notable the Linux kernel’s) that consisted of someone emailing the list with a unified patchfile, someone else with the right to directly commit replying with requested changes, a new patchfile being generated, and so on until finally the changes in the patch were judged okay and the patch was applied. A plain unadorned Git PR flow is nothing more than this in a very standardized format, with tools to do the fiddly bits. When using GitHub, the tools have been melded to ones allowing for line-by-line code comments and approvals, visual side-by-side diffing, etc. > What I am after is to add an example to a document page. > Is there any special thing about this other than just > asked for it? It sounds like I download my own copy > of the page (with git), then make the alterations, > then request others evaluate it? That’s all. You edit the file in your working directory where you want something changed, commit those changes locally to your personal Git repo clone, and submit it. It’s like modifying a wiki except that the changes aren’t immediate. The very easiest way (IMHO) to do this for a GitHub-hosted project like this is to navigate to the official repo on GitHub (here, https://github.com/raku/doc) while logged in to your GitHub account, and click “fork”. So you’ll have a toddandmargo/doc instead of raku/doc that forked from raku/doc at the moment you forked it. Then make your changes either of two ways: 1. More flexible but requiring more Git knowledge: clone your fork with its “remote origin” and “upstream” set such that you can run the “git pull” command to pull changes to the original docs repo through your fork and into your local working copy. The GitHub web UI gives instructions right there by the “clone” button on your fork’s page on how to do this. Then you make your changes locally, commit them locally, and push them up. When you visit your fork on the webpage (at, e.g., https://github.com/toddandmargo/docs) it will notice you just did this and offer a friendly notification complete with green button to turn your changes into a PR right there and take care of the fiddly bits. 2. Less flexible but easier, especially for small changes: use the GitHub web UI editing tools to just edit the files inline in your fork (at, e.g., https://github.com/toddandmargo/docs). GitHub will automatically generate the commits and again display a friendly prompt to create a pull request when you’re ready. Trey
