your command, without forgetting to ensure the `DEVELOPER`
flag is set, and with `GIT_TRACE` enabled so the debug output can be seen:

----
$ echo DEVELOPER=1 >>config.mak
$ make
$ GIT_TRACE=1 ./bin-wrappers/git walken
----

NOTE: For a more exhaustive overview of the new command process, take a look at
`Documentation/MyFirstContribution.adoc`.

NOTE: A reference implementation can be found at
https://github.com/nasamuffin/git/tree/revwalk.

=== `struct rev_cmdline_info`

The definition of `struct rev_cmdline_info` can be found in `revision.h`.

This struct is contained within the `rev_info` struct and is used to reflect
parameters provided by the user over the CLI.

`nr` represents the number of `rev_cmdline_entry` present in the array.

`alloc` is used by the `ALLOC_GROW` macro. Check `alloc.h` - this variable is
used to track the allocated size of the list.

Per entry, we find:

`item` is the object provided upon which to base the object walk. Items in Git
can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.adoc`.)

`name` is the object ID (OID) of the object - a hex string you may be familiar
with from using Git to organize your source in the past. Check the tutorial
mentioned above towards the top for a discussion of where the OID can come
from.

`whence` indicates some information about what to do with the parents of the
specified object. We'll explore this flag more later on; take a look at
`Documentation/revisions.adoc` to get an idea of what could set the `whence`
value.

`flags` are used to hint the beginning of the revision walk and are the first
block under the `#include`s in `revision.h`. The most likely ones to be set in
the `rev_cmdline_info` are `UNINTERESTING` and `BOTTOM`, but these same flags
can be used during the walk, as well.

=== `struct rev_info`

This one is quite a bit longer, and many fields are only used during the walk
by `revision.c` - not configuration options. Most of the configurable flags in
`struct rev_info` have a mirror in `Documentation/rev-list-options.adoc`. It's a
good idea to take some time and read through that document.

== Basic Commit Walk

First, let's see if we can replicate the output of `git log --oneline`. We'll
refer back to the implementation frequently to discover norms when performing
an object walk of our own.

To do so, we'll first find all the commits, in order, which preceded the current
commit. We'll extract the name and subject of the commit from each.

Ideally, we will also be able to find out which ones are currently at the tip of
various branches.

=== Setting Up

Preparing for your object walk has some distinct stages.

1. Perform default setup for this mode, and others which may be invoked.
2. Check configuration files for relevant settings.
3. Set up the `rev_info` struct.
4. Tweak the initialized `rev_info` to suit the current walk.
5. Prepare the `rev_info` for the walk.
6. Iterate over the objects, processing each one.

==== Default Setups

Before examining configuration files which may modify command behavior, set up
default state for switches or options your command may have. If your command
utilizes other Git components, ask them to set up their default states as well.
For instance, `git log` takes advantage of `grep` and `diff` functionality, so
its `init_log_defaults()` sets its own state (`decoration_style`) and asks
`grep` and `diff` to initialize themselves by calling each of their
initialization functions.

==== Configuring From `.gitconfig`

Next, we should have a look at any relevant configuration settings (i.e.,
settings readable and settable from `git config`). This is done by providing a
callback to `git_config()`; within that callback, you can also invoke methods
from other components you may need that need to intercept these options. Your
callback will be invoked once per each configuration value which Git knows about
(global, local, worktree, etc.).

Similarly to the default values, we don't have anything to do here yet