| Message ID | pull.177.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | documentation: add lab for first contribution | expand |
On 2019.04.11 11:32, Emily Shaffer via GitGitGadget wrote: > RFC. I am still working on adding a section on handling refs and objects. > > A tutorial for beginners explaining how to commit to git/git from clone to > push. This tutorial attempts to explain the GitGitGadget workflow; with the > review I'm hoping to understand whether it's worth the effort to detail how > to use git send-email as well. The linked implementation is present in my > personal fork and I'd be happy for any comments people wish to give against > that implementation, too, although it obviously isn't destined for git/git. > I wrote this guide in order to learn the process myself, so I welcome all > feedback. > > Additionally, if there are skills around working with the codebase that > should really be included in the "Implementation" section I'd be happy to > add them. > > Emily Shaffer (1): > documentation: add lab for first contribution > > Documentation/MyFirstContribution | 674 ++++++++++++++++++++++++++++++ > 1 file changed, 674 insertions(+) > create mode 100644 Documentation/MyFirstContribution > > > base-commit: e35b8cb8e212e3557efc565157ceb5cbaaf0d87f > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-177%2Fnasamuffin%2Fmyfirstcontrib-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-177/nasamuffin/myfirstcontrib-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/177 > -- > gitgitgadget Generally looks good to me! I definitely learned a few things. In the doc, you ask whether or not to cover the 'git send-email' workflow; I think it would be a good idea. It would also be nice to have the Documentation/Makefile automatically generate an HTML page for this; looks like you can follow SubmittingPatches as an example. I spotted a typo and a couple of whitespace issues; a fixup patch for this is included below. -- >8 -- Subject: [PATCH] fixup! documentation: add lab for first contribution --- Documentation/MyFirstContribution | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/MyFirstContribution b/Documentation/MyFirstContribution index 9b87e424d6..07c0b3f194 100644 --- a/Documentation/MyFirstContribution +++ b/Documentation/MyFirstContribution @@ -65,7 +65,7 @@ https://github.com/nasamuffin/git/tree/codelab. === Adding a new command Lots of the main useful commands are written as builtins, which means they are -implemented in C and compiled into the main `git` executable.. So it is +implemented in C and compiled into the main `git` executable. So it is informative to implement `git psuh` as a builtin. Create a new file in `builtin/` called `psuh.c`. @@ -111,7 +111,7 @@ The list of commands lives in `git.c`. We can register a new command by adding a cmd_struct to the commands[] array. struct cmd_struct takes a string with the command name, a function pointer to the command implementation, and a setup option flag. For now, let's keep cheating off of push. Find the line where -cmd_push is registered, copy it, and modify it for cmd_psuh. +cmd_push is registered, copy it, and modify it for cmd_psuh. The options are documented in `builtin.h` under "Adding a new built-in." Since we hope to print some data about the user's current workspace context later, @@ -608,7 +608,7 @@ your patch is accepted into `next`. TODO https://github.com/gitgitgadget/gitgitgadget/issues/83 It'd be nice to be able to verify that the patch looks good before sending it to everyone on Git mailing list. -=== Check Your Work +=== Check Your Work //// === Sending Your Patches
"Emily Shaffer via GitGitGadget" <gitgitgadget@gmail.com> writes:
> RFC. I am still working on adding a section on handling refs and objects.
Thanks. Is 'lab' understood widely enough? I _think_ you are
abbreviating what is known as 'codelab' by your colleagues at work,
but would it make it more in line with what we already have in this
project, perhaps, to call it a "tutorial"?
On Thu, Apr 11, 2019 at 7:35 PM Junio C Hamano <gitster@pobox.com> wrote: > > "Emily Shaffer via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > RFC. I am still working on adding a section on handling refs and objects. > > Thanks. Is 'lab' understood widely enough? I _think_ you are > abbreviating what is known as 'codelab' by your colleagues at work, > but would it make it more in line with what we already have in this > project, perhaps, to call it a "tutorial"? > I think you're right; I'll try to modify throughout. As part of that change I will also move the sample to a branch with a more descriptive name and change the URL. Thanks a lot for the detailed review, Junio. I expect to send a new patch later today, including an exercise in examining a specific commit.