the declaration of psuh; open up `builtin.h`, find the
declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
in order to keep the declarations alphabetically sorted:

----
int cmd_psuh(int argc, const char **argv, const char *prefix, struct repository *repo);
----

Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to
`#include "gettext.h"` to use functions related to printing output text.

Go ahead and add some throwaway printf to the `cmd_psuh` 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 UNUSED, const char **argv UNUSED,
	     const char *prefix UNUSED, struct repository *repo UNUSED)
{
	printf(_("Pony saying hello goes here.\n"));
	return 0;
}
----

Let's try to build it.  Open `Makefile`, find where `builtin/pull.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.

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 (immediately before `cmd_pull`).

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.

Go ahead and build again. You should see a clean build, so let's kick the tires
and see if it works. There's a binary you can use to test with in the
`bin-wrappers` directory.

----
$ ./bin-wrappers/git psuh
----

Check it out! You've got a command! Nice work! Let's commit this.

`git status` reveals modified `Makefile`, `builtin.h`, and `git.c` as well as
untracked `builtin/psuh.c` and `git-psuh`. First, let's take care of the binary,
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