string; `pretty.h` has an extremely handy `pp_commit_easy()` call which doesn't
require a full format object to be passed.

Add the following includes:

----
#include "commit.h"
#include "pretty.h"
----

Then, add the following lines within your implementation of `cmd_psuh()` near
the declarations and the logic, respectively.

----
	struct commit *c = NULL;
	struct strbuf commitline = STRBUF_INIT;

...

	c = lookup_commit_reference_by_name("origin/master");

	if (c != NULL) {
		pp_commit_easy(CMIT_FMT_ONELINE, c, &commitline);
		printf(_("Current commit: %s\n"), commitline.buf);
	}
----

The `struct strbuf` provides some safety belts to your basic `char*`, one of
which is a length member to prevent buffer overruns. It needs to be initialized
nicely with `STRBUF_INIT`. Keep it in mind when you need to pass around `char*`.

`lookup_commit_reference_by_name` resolves the name you pass it, so you can play
with the value there and see what kind of things you can come up with.

`pp_commit_easy` is a convenience wrapper in `pretty.h` that takes a single
format enum shorthand, rather than an entire format struct. It then
pretty-prints the commit according to that shorthand. These are similar to the
formats available with `--pretty=FOO` in many Git commands.

Build it and run, and if you're using the same name in the example, you should
see the subject line of the most recent commit in `origin/master` that you know
about. Neat! Let's commit that as well.

----
$ git add builtin/psuh.c
$ git commit -sm "psuh: display the top of origin/master"
----

[[add-documentation]]
=== Adding Documentation

Awesome! You've got a fantastic new command that you're ready to share with the
community. But hang on just a minute - this isn't very user-friendly. Run the
following:

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

Your new command is undocumented! Let's fix that.

Take a look at `Documentation/git-*.adoc`. These are the manpages for the
subcommands that Git knows about. You can open these up and take a look to get
acquainted with the format, but then go ahead and make a new file
`Documentation/git-psuh.adoc`. Like with most of the documentation in the Git
project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing
Documentation" section). Use the following template to fill out your own
manpage:

// Surprisingly difficult to embed AsciiDoc source within AsciiDoc.
[listing]
....
git-psuh(1)
===========

NAME
----
git-psuh - Delight users' typo with a shy horse


SYNOPSIS
--------
[verse]
'git-psuh [<arg>...]'

DESCRIPTION
-----------
...

OPTIONS[[OPTIONS]]
------------------
...

OUTPUT
------
...

GIT
---
Part of the linkgit:git[1] suite
....

The most important pieces of this to note are the file header, underlined by =,
the NAME section, and the SYNOPSIS, which would normally contain the grammar if
your command took arguments. Try to use well-established manpage headers so your
documentation is consistent with other Git and UNIX manpages; this makes life
easier for your user, who can skip to the section they know contains the
information they need.

NOTE: Before trying to build the docs, make sure you have the package `asciidoc`
installed.

Now that you've written your manpage, you'll need to build it explicitly. We
convert your AsciiDoc to troff which is man-readable like so:

----
$ make all doc
$ man Documentation/git-psuh.1
----

or

----
$ make -C Documentation/ git-psuh.1
$ man Documentation/git-psuh.1
----

While this isn't as satisfying as running through `git help`, you can at least
check that your help page looks right.

You can also check that the documentation coverage is good (that is, the project
sees that your command has been implemented as well as documented) by running
`make check-docs` from the top-level.

Go ahead and commit your new documentation change.

[[add-usage]]
=== Adding Usage Text

Try and run `./bin-wrappers/git psuh -h`. Your command should crash at the end.
That's because `-h` is a special case