All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elia Pinto <gitter.spiros@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 1/2] imap-send.c: implements the GIT_CURL_DEBUG environment variable
Date: Mon, 4 Apr 2016 18:08:38 +0200	[thread overview]
Message-ID: <CA+EOSBkY-Tsz3ZAfK3uAXJsrE585cOhyxjsU4FhgDMFC-ypkUg@mail.gmail.com> (raw)
In-Reply-To: <xmqqtwjljq97.fsf@gitster.mtv.corp.google.com>

2016-04-01 17:35 GMT+02:00 Junio C Hamano <gitster@pobox.com>:
> Elia Pinto <gitter.spiros@gmail.com> writes:
>
>> Implements the GIT_CURL_DEBUG environment variable to allow a greater
>> degree of detail of GIT_CURL_VERBOSE, in particular the complete
>> transport header and all the data payload exchanged.
>> It might be useful if a particular situation could require a more
>> thorough debugging analysis.
>
> My impression is that using GIT_TRACE_* is the more mainstream
> trend, and it may be beneficial to work any new debugging aid like
> this one to fit within that mechanism.

I thought about it, and I agree with you. The idea could be

- Call the variable GIT_TRACE_CURL_DEBUG instead
- Add the new GIT_TRACE_CURL_VERBOSE variable, keeping
GIT_CURL_VERBOSE for compatibility
- Documenting these GIT_TRACE_CURL_XXX variables (GIT_CURL_VERBOSE
it is not even documented i think)
- perhaps use the git trace api in doing these new patches

Look reasonable? It seems reasonable? I'd like your own opinion

Thank you for your suggestion
>
> I am not saying new GIT_*_DEBUG is wrong.  I just wanted to make
> sure you have considered doing this as a new trace in GIT_TRACE_*
> family and rejected that apporach with a very good reason, in
> which case that rationale deserves to be in the log message.

  reply	other threads:[~2016-04-04 16:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01 10:44 [PATCH 1/2] imap-send.c: implements the GIT_CURL_DEBUG environment variable Elia Pinto
2016-04-01 10:44 ` [PATCH 2/2] http.c: " Elia Pinto
2016-04-01 15:03   ` Ramsay Jones
2016-04-04 12:41     ` Elia Pinto
2016-04-01 11:44 ` [PATCH 1/2] imap-send.c: " Torsten Bögershausen
2016-04-01 14:56 ` Ramsay Jones
2016-04-04 12:45   ` Elia Pinto
2016-04-01 15:35 ` Junio C Hamano
2016-04-04 16:08   ` Elia Pinto [this message]
2016-04-04 16:50     ` Junio C Hamano
2016-04-01 20:25 ` Eric Sunshine
2016-04-05 10:21   ` Elia Pinto
2016-04-06  5:53     ` Eric Sunshine
2016-04-06  6:16       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+EOSBkY-Tsz3ZAfK3uAXJsrE585cOhyxjsU4FhgDMFC-ypkUg@mail.gmail.com \
    --to=gitter.spiros@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.