Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I make regular use of our tracing infrastructure when I'm debugging a problem, frequently adding
git_trace
statements to the code so that I can get debugging output while I'm working on a problem.(
git_trace
has benefits over simpleprintf
debugging, since language bindings can plug in to the trace framework and send trace output to a log location, debugger output, etc.)We've never built tracing into the library by default. This was because we were super conservative about it in ye olde days to avoid any perf issues. However, we've also been super conservative about the way tracing works (it's basically a simple test and any tracing is skipped if the trace level is below a certain point). And we've been even more conservative about checking in
git_trace
logging into the library.So there's no harm in enabling tracing support by default.
Similarly, we should emit better trace information in clar. Now
GIT_TRACE_LEVEL
is obeyed, the tracelevel is shown when the trace is printed, and by default the noisy test tracing is disabled (can be re-enabled withGIT_TRACE_TESTS
environment variable.)