Re: [PATCH v6 1/2] documentation: add tutorial for first contribution

["SZEDER Gábor" <szeder.dev@gmail.com>]

On Fri, May 17, 2019 at 12:07:02PM -0700, Emily Shaffer wrote:
> +=== Adding a New Command
> +
> +Lots of the subcommands are written as builtins, which means they are
> +implemented in C and compiled into the main `git` executable. Implementing the
> +very simple `psuh` command as a built-in will demonstrate the structure of the
> +codebase, the internal API, and the process of working together as a contributor
> +with the reviewers and maintainer to integrate this change into the system.
> +
> +Built-in subcommands are typically implemented in a function named "cmd_"
> +followed by the name of the subcommand, in a source file named after the
> +subcommand and contained within `builtin/`. So it makes sense to implement your
> +command in `builtin/psuh.c`. Create that file, and within it, write the entry
> +point for your command in a function matching the style and signature:
> +
> +----
> +int cmd_psuh(int argc, const char **argv, const char *prefix)
> +----
> +
> +We'll also need to add the declaration of psuh; open up `builtin.h`, find the
> +declaration for `cmd_push`, and add a new line for `psuh` immediately before it,
> +in order to keep the declarations sorted:
> +
> +----
> +int cmd_psuh(int argc, const char **argv, const char *prefix);
> +----
> +
> +Be sure to `#include "builtin.h"` in your `psuh.c`.
> +
> +Go ahead and add some throwaway printf to that function. This is a decent
> +starting point as we can now add build rules and register the command.
> +
> +NOTE: Your throwaway text, as well as much of the text you will be adding over
> +the course of this tutorial, is user-facing. That means it needs to be
> +localizable. Take a look at `po/README` under "Marking strings for translation".
> +Throughout the tutorial, we will mark strings for translation as necessary; you
> +should also do so when writing your user-facing commands in the future.
> +
> +----
> +int cmd_psuh(int argc, const char **argv, const char *prefix)
> +{
> +	printf(_("Pony saying hello goes here.\n"));
> +	return 0;
> +}
> +----
> +
> +Let's try to build it.  Open `Makefile`, find where `builtin/push.o` is added
> +to `BUILTIN_OBJS`, and add `builtin/psuh.o` in the same way next to it in
> +alphabetical order. Once you've done so, move to the top-level directory and
> +build simply with `make`. Also add the `DEVELOPER=1` variable to turn on
> +some additional warnings:
> +
> +----
> +$ echo DEVELOPER=1 >config.mak
> +$ make
> +----
> +
> +NOTE: When you are developing the Git project, it's preferred that you use the
> +`DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn
> +it off, but it's a good idea to mention the problem to the mailing list.
> +
> +NOTE: The Git build is parallelizable. `-j#` is not included above but you can
> +use it as you prefer, here and elsewhere.
> +
> +Great, now your new command builds happily on its own. But nobody invokes it.
> +Let's change that.
> +
> +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 mimicking `push`. Find the line where
> +`cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new
> +line in alphabetical order.
> +
> +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,
> +we need a Git directory, so choose `RUN_SETUP` as your only option.

Just leaving a quick note here: an entry about the new command should
be added to 'command-list.txt' as well, so it will be included in the
list of available commands in 'git help -a' or even in 'git help'
and in completion, if the command is marked with the necessary
attributes.