@@ -1211,15 +1211,15 @@ static struct ref *get_refs_list_using_list(struct transport *transport,
helper = get_helper(transport);
if (data->object_format) {
- write_str_in_full(helper->in, "option object-format\n");
+ write_constant(helper->in, "option object-format\n");
if (recvline(data, &buf) || strcmp(buf.buf, "ok"))
exit(128);
}
if (data->push && for_push)
- write_str_in_full(helper->in, "list for-push\n");
+ write_constant(helper->in, "list for-push\n");
else
- write_str_in_full(helper->in, "list\n");
+ write_constant(helper->in, "list\n");
while (1) {
char *eov, *eon;
The transport-helper code provides some functions for writing to the helper process, but there are a few spots that don't use them. We should do so consistently because: 1. They detect errors on write (though in practice this means the helper process went away, and we'd see the problem as soon as we try to read the response). 2. They dump the written bytes to the GIT_TRANSPORT_HELPER_DEBUG stream. It's doubly confusing to miss some writes but not others, as you see a partial conversation. The "list" ones go all the way back to the beginning of the transport helper code; they were just missed when most writes were converted in bf3c523c3f (Add remote helper debug mode, 2009-12-09). The nearby "object-format" write presumably just cargo-culted them, as it's only a few lines away. Signed-off-by: Jeff King <peff@peff.net> --- I also find the output kind of verbose (especially the constant "waiting" lines), and because it's not GIT_TRACE_TRANSPORT_HELPER, it's annoying to use with the test scripts (it gets eaten by the test harness, and you can't even redirect it to an alternative file). So I was tempted to convert it, but it felt like too deep a rabbit hole for today. transport-helper.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)