On 2020-01-17 13:47, Trey Harris wrote:
On Fri, Jan 17, 2020 at 15:44 ToddAndMargo via perl6-users
<perl6-users@perl.org <mailto: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
Hi Trey,
I wanted to add an example to
https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT
Do I Git the entire documentation project to do so?
Can I jsut Git that page? If so, where do I find
it to Git?
And when I ask for an evaluation, do they have to dig
through the entire project to find my additions?
I am confused,
-T
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
