add some attributes about the
command which impacts where it shows up in the aforementioned help commands. The
top of `command-list.txt` shares some information about what each attribute
means; in those help pages, the commands are sorted according to these
attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
"mainporcelain". For "mainporcelain" commands, the comments at the top of
`command-list.txt` indicate we can also optionally add an attribute from another
list; since `git psuh` shows some information about the user's workspace but
doesn't modify anything, let's mark it as "info". Make sure to keep your
attributes in the same style as the rest of `command-list.txt` using spaces to
align and delineate them:

----
git-prune-packed                        plumbingmanipulators
git-psuh                                mainporcelain		info
git-pull                                mainporcelain           remote
git-push                                mainporcelain           remote
----

Build again. Now, when you run with `-h`, you should see your usage printed and
your command terminated before anything else interesting happens. Great!

Go ahead and commit this one, too.

[[testing]]
== Testing

It's important to test your code - even for a little toy command like this one.
Moreover, your patch won't be accepted into the Git tree without tests. Your
tests should:

* Illustrate the current behavior of the feature
* Prove the current behavior matches the expected behavior
* Ensure the externally-visible behavior isn't broken in later changes

So let's write some tests.

Related reading: `t/README`

[[overview-test-structure]]
=== Overview of Testing Structure

The tests in Git live in `t/` and are named with a 4-digit decimal number using
the schema shown in the Naming Tests section of `t/README`.

[[write-new-test]]
=== Writing Your Test

Since this a toy command, let's go ahead and name the test with t9999. However,
as many of the family/subcmd combinations are full, best practice seems to be
to find a command close enough to the one you've added and share its naming
space.

Create a new file `t/t9999-psuh-tutorial.sh`. Begin with the header as so (see
"Writing Tests" and "Source 'test-lib.sh'" in `t/README`):

----
#!/bin/sh

test_description='git-psuh test

This test runs git-psuh and makes sure it does not crash.'

. ./test-lib.sh
----

Tests are framed inside of a `test_expect_success` in order to output TAP
formatted results. Let's make sure that `git psuh` doesn't exit poorly and does
mention the right animal somewhere:

----
test_expect_success 'runs correctly with no args and good output' '
	git psuh >actual &&
	grep Pony actual
'
----

Indicate that you've run everything you wanted by adding the following at the
bottom of your script:

----
test_done
----

Make sure you mark your test script executable:

----
$ chmod +x t/t9999-psuh-tutorial.sh
----

You can get an idea of whether you created your new test script successfully
by running `make -C t test-lint`, which will check for things like test number
uniqueness, executable bit, and so on.

[[local-test]]
=== Running Locally

Let's try and run locally:

----
$ make
$ cd t/ && prove t9999-psuh-tutorial.sh
----

You can run the full test suite and ensure `git-psuh` didn't break anything:

----
$ cd t/
$ prove -j$(nproc) --shuffle t[0-9]*.sh
----

NOTE: You can also do this with `make test` or use any testing harness which can
speak TAP. `prove` can run concurrently. `shuffle` randomizes the order the
tests are run in, which makes them resilient against unwanted inter-test
dependencies. `prove` also makes the output nicer.

Go ahead and commit this change, as well.

[[ready-to-share]]
== Getting Ready to Share: Anatomy of a Patch Series

You may have noticed already that the Git project performs its code reviews via
emailed patches, which are then applied by the maintainer when they are ready
and approved by the community. The Git project does not accept