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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
