Thread (26 messages) flat view 26 messages, 7 authors, 2016-06-15

Re: [PATCH 8/8] trace: give repo_setup trace its own key

From: Jeff King <hidden>
Date: 2016-06-15 22:50:39

On Thu, Feb 24, 2011 at 04:59:50PM +0100, Andreas Ericsson wrote:
On 02/24/2011 03:30 PM, Jeff King wrote:
quoted
You no longer get this output with GIT_TRACE=1; instead, you
can do GIT_TRACE_SETUP=1.
It would be beneficial if GIT_TRACE still turned on tracing globally
so one doesn't have to know all flags to start tracing for errors.

I also imagine running GIT_TRACE=1 <command> as the first step would
be quite useful for when one's not entirely certain where the problem
lies and then use the specific tracing flag when trying to fix it.
Yeah, I considered that GIT_TRACE should become "trace everything" and
the existing traces split up into specific keys. I had a few concerns:

  - Having this splitting mechanism gives us room to add debugging code
    that is probably not interesting, but may be if you are working on a
    specific problem, without having to worry about spamming people.
    Which means GIT_TRACE may eventually become unreadably verbose.

    Maybe GIT_TRACE should include some traces, but not others (like
    packet debugging, or giant diff state dumps).

  - I didn't want to change the meaning of GIT_TRACE too much, because
    it is advice that everybody knows (in docs, mailing list archives,
    etc).

But those are not strong objections. Just giving the rationale I used
while writing the patches. I'd be curious what others think.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help