> This should be integrated with the trace2 sub-system, and I would appreciate > pointers on how to start. The trace2 subsystem seems to be designed to detect errors coarsely (e.g. by looking at process invocations) and log timings. It currently doesn't seem to be made for this kind of fine debugging information - and perhaps this is by design, because such logging information would not be useful to most users and would just clutter up the logs. But I think there is a place for this in Git - in particular, we have packet tracing (GIT_TRACE_PACKET), and this has been useful both in automated tests (t/????-*.sh) and in manual tests. Ref backend tracing seems to be similar. But this would be best if we had an additional option that could control whether ref backend tracing was on or off, independent from other things like the trace2 target. Is the plan to migrate all usages of "trace" to "trace2" or for both to exist simultaneously? If the latter, then ref backend tracing could just use "trace", but if the former, we'd have to designing this additional option.
