Re: [PATCH 0/1] documentation: add lab for first contribution
- Date: Thu, 11 Apr 2019 14:03:22 -0700
- From: Josh Steadmon <steadmon@xxxxxxxxxx>
- Subject: Re: [PATCH 0/1] documentation: add lab for first contribution
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
> 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
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
@@ -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`.
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