Re: [PATCH 0/1] documentation: add lab for first contribution

[Josh Steadmon <steadmon@google.com>]

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
-- 
2.21.0.392.gf8f6787159e-goog