A few weeks ago in: http://article.gmane.org/gmane.comp.version-control.git/165496 we discussed the possibility of removing the repo setup trace lines. I mentioned that I had also recently done some debug code that would not be appropriate to show all the time with GIT_TRACE. So here is a series that jumbles it all together: refactors the trace code to handle multiple environment variables, adds packet-tracing code on its own variable, and puts the repo setup traces on their own variable. With this, you can do: GIT_TRACE=1 \ GIT_TRACE_PACKET=/tmp/packet.dump \ GIT_TRACE_SETUP=0 \ git whatever There may be a few other places where it is worth either pushing some traces to their variable (I think the notes merge code has some debugging traces in it), or places where existing debugging code could be enabled (e.g., there is some diffcore debugging code that I sometimes turn on; it is not even compiled by default, but this would give a nice way of pushing that decision to runtime). I have mixed feelings on adding a bunch of debugging code. On the one hand, it's mostly dead code that nobody runs. On the other hand, it is sometimes really helpful to be able to tell a user "run with this environment variable and tell us what it says" without having to get them to apply a custom patch. [1/8]: compat: provide a fallback va_copy definition [2/8]: strbuf: add strbuf_addv [3/8]: trace: add trace_vprintf [4/8]: trace: refactor to support multiple env variables [5/8]: trace: factor out "do we want to trace" logic [6/8]: trace: add trace_strbuf [7/8]: add packet tracing debug code [8/8]: trace: give repo_setup trace its own key -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