@@ -40,14 +40,6 @@ the list by sending an email to <git+subscribe@vger.kernel.org>
4040The https://lore.kernel.org/git[archive] of this mailing list is
4141available to view in a browser.
4242
43- ==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com]
44-
45- This mailing list is targeted to new contributors and was created as a place to
46- post questions and receive answers outside of the public eye of the main list.
47- Veteran contributors who are especially interested in helping mentor newcomers
48- are present on the list. In order to avoid search indexers, group membership is
49- required to view messages; anyone can join and no approval is required.
50-
5143==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat
5244
5345This IRC channel is for conversations between Git contributors. If someone is
@@ -150,15 +142,31 @@ command in `builtin/psuh.c`. Create that file, and within it, write the entry
150142point for your command in a function matching the style and signature:
151143
152144----
153- int cmd_psuh(int argc, const char **argv, const char *prefix)
145+ int cmd_psuh(int argc UNUSED, const char **argv UNUSED,
146+ const char *prefix UNUSED, struct repository *repo UNUSED)
154147----
155148
149+ A few things to note:
150+
151+ * A subcommand implementation takes its command line arguments
152+ in `int argc` + `const char **argv`, like `main()` would.
153+
154+ * It also takes two extra parameters, `prefix` and `repo`. What
155+ they mean will not be discussed until much later.
156+
157+ * Because this first example will not use any of the parameters,
158+ your compiler will give warnings on unused parameters. As the
159+ list of these four parameters is mandated by the API to add
160+ new built-in commands, you cannot omit them. Instead, you add
161+ `UNUSED` to each of them to tell the compiler that you *know*
162+ you are not (yet) using it.
163+
156164We'll also need to add the declaration of psuh; open up `builtin.h`, find the
157165declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
158166in order to keep the declarations alphabetically sorted:
159167
160168----
161- int cmd_psuh(int argc, const char **argv, const char *prefix);
169+ int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo );
162170----
163171
164172Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to
@@ -174,7 +182,8 @@ Throughout the tutorial, we will mark strings for translation as necessary; you
174182should also do so when writing your user-facing commands in the future.
175183
176184----
177- int cmd_psuh(int argc, const char **argv, const char *prefix)
185+ int cmd_psuh(int argc UNUSED, const char **argv UNUSED,
186+ const char *prefix UNUSED, struct repository *repo UNUSED)
178187{
179188 printf(_("Pony saying hello goes here.\n"));
180189 return 0;
@@ -287,8 +296,9 @@ on the reference implementation linked at the top of this document.
287296It's probably useful to do at least something besides printing out a string.
288297Let's start by having a look at everything we get.
289298
290- Modify your `cmd_psuh` implementation to dump the args you're passed, keeping
291- existing `printf()` calls in place:
299+ Modify your `cmd_psuh` implementation to dump the args you're passed,
300+ keeping existing `printf()` calls in place; because the args are now
301+ used, remove the `UNUSED` macro from them:
292302
293303----
294304 int i;
@@ -312,26 +322,27 @@ on the command line, including the name of our command. (If `prefix` is empty
312322for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
313323helpful. So what other context can we get?
314324
315- Add a line to `#include "config.h"`. Then, add the following bits to the
325+ Add a line to `#include "config.h"` and `#include "repository.h"`.
326+ Then, add the following bits to the function body:
316327function body:
317328
318329----
319330 const char *cfg_name;
320331
321332...
322333
323- git_config( git_default_config, NULL);
324- if (git_config_get_string_tmp( "user.name", &cfg_name) > 0 )
334+ repo_config(repo, git_default_config, NULL);
335+ if (repo_config_get_string_tmp(repo, "user.name", &cfg_name))
325336 printf(_("No name is found in config\n"));
326337 else
327338 printf(_("Your name: %s\n"), cfg_name);
328339----
329340
330- `git_config ()` will grab the configuration from config files known to Git and
331- apply standard precedence rules. `git_config_get_string_tmp ()` will look up
341+ `repo_config ()` will grab the configuration from config files known to Git and
342+ apply standard precedence rules. `repo_config_get_string_tmp ()` will look up
332343a specific key ("user.name") and give you the value. There are a number of
333344single-key lookup functions like this one; you can see them all (and more info
334- about how to use `git_config ()`) in `Documentation/technical/api-config.adoc`.
345+ about how to use `repo_config ()`) in `Documentation/technical/api-config.adoc`.
335346
336347You should see that the name printed matches the one you see when you run:
337348
@@ -364,9 +375,10 @@ status_init_config(&s, git_status_config);
364375----
365376
366377But as we drill down, we can find that `status_init_config()` wraps a call
367- to `git_config ()`. Let's modify the code we wrote in the previous commit.
378+ to `repo_config ()`. Let's modify the code we wrote in the previous commit.
368379
369380Be sure to include the header to allow you to use `struct wt_status`:
381+
370382----
371383#include "wt-status.h"
372384----
@@ -379,8 +391,8 @@ prepare it, and print its contents:
379391
380392...
381393
382- wt_status_prepare(the_repository , &status);
383- git_config( git_default_config, &status);
394+ wt_status_prepare(repo , &status);
395+ repo_config(repo, git_default_config, &status);
384396
385397...
386398
0 commit comments