On Fri, Jun 12, 2015 at 02:00:05PM -0400, Jeff King wrote: > When I added GIT_TRACE_PACKET long ago, I had always intended to > follow-up with a GIT_TRACE_PACKFILE. The former stops tracing when we > get to the binary data, but I had intended the latter to store the pure > on-the-wire packfile transmission for later debugging to. I never got > around to it, but I think it is something like the patch below. Here it is, a bit more cleaned up. I think this is a nice improvement, and it does fix some minor issues in the existing GIT_TRACE_PACKET code. But I don't think it will ever work for receive-pack, because we hand off the socket directly to index-pack. I can live with that. But another approach would be to make it easier to capture the stdin of programs with GIT_TRACE, rather than just their arguments. That makes it more generically usable (e.g., I have hacky patches on our servers for capturing "pack-objects" input so I can replay expensive fetch requests). As Augie noted, that's not a full pack-file due to the --pack-header stuff. But given a full trace (which has both the arguments and stdin), you could reconstruct the packfile, which we could do as a post-processing step. I dunno. I prefer introducing a nicely generic mechanism, but it would probably be a little more irritating to use in practice. I guess yet another way to do it would be to put the GIT_TRACE_PACK intelligence into index-pack and unpack-objects (rather than fetch-pack). Then it at least applies to both the pushing and fetching sides. Anyway, here are the patches I came up with: [1/3]: pkt-line: simplify starts_with checks in packet tracing [2/3]: pkt-line: tighten sideband PACK check when tracing [3/3]: pkt-line: support tracing verbatim pack contents -Peff -- 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