which should be ignored. Open `.gitignore` in your editor, find `/git-pull`, and
add an entry for your new command in alphabetical order:

----
...
/git-prune-packed
/git-psuh
/git-pull
/git-push
/git-quiltimport
/git-range-diff
...
----

Checking `git status` again should show that `git-psuh` has been removed from
the untracked list and `.gitignore` has been added to the modified list. Now we
can stage and commit:

----
$ git add Makefile builtin.h builtin/psuh.c git.c .gitignore
$ git commit -s
----

You will be presented with your editor in order to write a commit message. Start
the commit with a 50-column or less subject line, including the name of the
component you're working on, followed by a blank line (always required) and then
the body of your commit message, which should provide the bulk of the context.
Remember to be explicit and provide the "Why" of your change, especially if it
couldn't easily be understood from your diff. When editing your commit message,
don't remove the `Signed-off-by` trailer which was added by `-s` above.

----
psuh: add a built-in by popular demand

Internal metrics indicate this is a command many users expect to be
present. So here's an implementation to help drive customer
satisfaction and engagement: a pony which doubtfully greets the user,
or, a Pony Saying "Um, Hello" (PSUH).

This commit message is intentionally formatted to 72 columns per line,
starts with a single line as "commit message subject" that is written as
if to command the codebase to do something (add this, teach a command
that). The body of the message is designed to add information about the
commit that is not readily deduced from reading the associated diff,
such as answering the question "why?".

Signed-off-by: A U Thor <author@example.com>
----

Go ahead and inspect your new commit with `git show`. "psuh:" indicates you
have modified mainly the `psuh` command. The subject line gives readers an idea
of what you've changed. The sign-off line (`-s`) indicates that you agree to
the Developer's Certificate of Origin 1.1 (see the
`Documentation/SubmittingPatches` +++[[dco]]+++ header).

For the remainder of the tutorial, the subject line only will be listed for the
sake of brevity. However, fully-fleshed example commit messages are available
on the reference implementation linked at the top of this document.

[[implementation]]
=== Implementation

It's probably useful to do at least something besides printing out a string.
Let's start by having a look at everything we get.

Modify your `cmd_psuh` implementation to dump the args you're passed,
keeping existing `printf()` calls in place; because the args are now
used, remove the `UNUSED` macro from them:

----
	int i;

	...

	printf(Q_("Your args (there is %d):\n",
		  "Your args (there are %d):\n",
		  argc),
	       argc);
	for (i = 0; i < argc; i++)
		printf("%d: %s\n", i, argv[i]);

	printf(_("Your current working directory:\n<top-level>%s%s\n"),
	       prefix ? "/" : "", prefix ? prefix : "");

----

Build and try it. As you may expect, there's pretty much just whatever we give
on the command line, including the name of our command. (If `prefix` is empty
for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
helpful. So what other context can we get?

Add a line to `#include "config.h"` and `#include "repository.h"`.
Then, add the following bits to the function body:
function body:

----
	const char *cfg_name;

...

	repo_config(repo, git_default_config, NULL);
	if (repo_config_get_string_tmp(repo, "user.name", &cfg_name))
		printf(_("No name is found in config\n"));
	else
		printf(_("Your name: %s\n"), cfg_name);
----

`repo_config()` will grab the configuration from config files known to Git and
apply standard precedence rules. `repo_config_get_string_tmp()` will look up
a specific key ("user.name") and give you the value. There are a number of
single-key lookup functions like this one; you can see them all (and more info
about how to use `repo_config()`)