Another thing.
As currently written, the "dump" server is strictly one-request,
one-response interface.
I can easily see the command set to be extended to allow
transfer of richer set of data (e.g. whether a ref is a symref
and if so where it points at, querying config variables). Also,
if you want to write a repository browser using this "dump"
server, you would first throw a commit at it, learn its parents
and its tree, and then you suddenly have _many_ objects that you
can simultaneously ask about without doing one-request,
one-response exchange.
So it might make sense to base this not on line-per-line message
format using strbuf_getline() interface, but base it instead on
packet_read_line()/packet_write() interface, and explicitly mark
the end of a batch of request with packet_flush(). That would
allow the "protocol" stream, which would matter even more when
you run this over the network, perhaps via git-daemon and/or
from connect.c