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
