Ok, so each key has a corresponding callback that is used to get its
value. This works fine when we have one operation/callback per key, but
I could see this being a bit inflexible in cases where performing a
single operation could be expected to generate multiple keys worth of
information at a time.

For git-repo-info it wouldn't be a problem, as we return one value per
requested key.

However, I plan to add a feature in the future for requesting a group
of fields. For example:

$ git repo info layout
layout.bare=true
layout.shallow=false

which, of course, is not what exactly you mean :-). But it is a similar
problem of requesting one key and getting several key-value pairs.

I certainly see this being the case with git-repo-stats where, for
example, interating over references will produce multiple keyvalues
indicating the number of branches, tags, remotes, etc. But, maybe for
git-repo-info this will not be as much of a concern?

For git-repo-info it isn't, at least by the planned set of values.
However, given that I have plans to add the previous feature, I can
try to make it flexible for doing things like:

$ git repo stats object.count
object.count.blob=123
object.count.tree=456
object.count.commit=789

So you can use the same code for outputting git-repo-stats data. By
now, I plan to finish the basic functionality (i.e. finishing this
"skeleton" and adding the rest of the proposed fields), then I'll
think about this feature.

I think the current solution is simple enough to being refactored to
support this kind of thing in the future.

If the user does not input any keys, we simply do nothing. I do wonder
if this is really the best default behavior.

In previous versions it returned all the available fields. There was a
`--allow-empty` flag that allowed to request no field.

After the discussion in [1] we agreed that it would be better to return
nothing by default and add a `--all` flag for returning all the fields
(or a default set of fields).