Jeff King <peff@xxxxxxxx> writes: > My other motive for trace.* was that we could have something like > "trace.prune", and have git-prune provide verbose debugging information. > We have custom patches like that on GitHub servers, which we've used to > debug occasional weirdness (e.g., you find that an object is missing > from a repo, but you have no clue why it went away; was it never there, > did somebody prune it, did it get dropped from a pack?). > > I can send those upstream, but it would be nice not to introduce a > totally separate tracing facility when trace_* is so close. But it > needs: > > 1. To be enabled by config, not environment. > > 2. To support some basic output filename flexibility so the output can > be organized (we write the equivalent of GIT_TRACE_FOO to > $GIT_DIR/ghlog_foo/YYYY-MM-DD/YYYY-MM-DDTHH:MM:SS.PID). > > For (1), we could just load trace.* in git_default_config; you couldn't > use it with any "early" tracing that happens before then, but I think in > practice it would be fine for most traces. > > For (2), I think we could accomplish that with %-placeholders (like my > earlier patch), and the ability to write relative paths into $GIT_DIR > (again, you couldn't do this for "early" traces, but you could for other > stuff). Both sounds like a sensible compromise to me. Thanks, all, for an interesting discussion. -- 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