On Tue, Jun 16, 2015 at 1:10 PM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Jun 16, 2015 at 11:38:41AM -0400, Augie Fackler wrote: > >> > We already have a GIT_TRACE_PACKET mechanism for tracing >> > packets. Let's extend it with GIT_TRACE_PACK to dump the >> > verbatim packfile. >> >> FWIW, this also works for me - I have no preference between my patches >> and Jeff's. I suspect yours are much better given that you have a clue >> about git internals ;). > > I like mine better than yours, if only because it hooks into the > existing tracing mechanism. But I am sad that neither of our proposals > works for tracing pushed packs (something that is useful for the > opposite situation: you have a sane git server, and some unknown > misbehaving _client_ is sending you bogus packs). Yeah, not having it for the push side is a slight bummer, but in general I haven't had problems debugging git clients pushing bogus data in the same way that I've had problems with weirdness in new server features. > > Here's a rough cut at the "trace stdin" idea I mentioned earlier (which > is essentially an internal "tee"). You can collect the incoming pack > like: Neat, but not sure I like the extra overhead of having to grab the full trace and then reconstruct some arguments to be able to diagnose the pack. Having the verbatim pack just land on disk is really handy, because then any existing tools one has cooked up (my team has a few weird one-off ones by now) just work without extra fussing or looking up steps to reconstruct the whole file. -- 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