From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 26 Jun 2015 18:47:03 GMT
Subject: Re: [PATCH 3/3] trace: add GIT_TRACE_STDIN
Message-ID: <xmqqoak2tihk.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150617191023.GA25304@peff.net>

Jeff King <peff@peff.net> 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.