From: Junio C Hamano <gitster@pobox•com>
To: Augie Fackler <augie@google•com>
Cc: Jeff King <peff@peff•net>, Johannes Sixt <j6t@kdbg•org>,
git@vger•kernel.org, Stefan Beller <sbeller@google•com>
Subject: Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents
Date: Tue, 16 Jun 2015 09:39:19 -0700 [thread overview]
Message-ID: <xmqqvben6214.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAHcr6HYvVR4uTmtegWHK0h+v_aVs4JVLsSwvjthGY3pb=-Q0yQ@mail.gmail.com> (Augie Fackler's message of "Tue, 16 Jun 2015 11:38:41 -0400")
Augie Fackler <augie@google•com> writes:
> On Fri, Jun 12, 2015 at 5:28 PM, Jeff King <peff@peff•net> wrote:
>> When debugging the pack protocol, it is sometimes useful to
>> store the verbatim pack that we sent or received on the
>> wire. Looking at the on-disk result is often not helpful for
>> a few reasons:
>>
>> 1. If the operation is a clone, we destroy the repo on
>> failure, leaving nothing on disk.
>>
>> 2. If the pack is small, we unpack it immediately, and the
>> full pack never hits the disk.
>>
>> 3. If we feed the pack to "index-pack --fix-thin", the
>> resulting pack has the extra delta bases added to it.
>>
>> We already have a GIT_TRACE_PACKET mechanism for tracing
>> packets. Let's extend it with GIT_TRACE_PACK to dump the
>> verbatim packfile.
>
> FWIW, this also works for me - I have no preference between my patches
> and Jeff's. I suspect yours are much better given that you have a clue
> about git internals ;).
>
> One bit of feedback is that it might be worth mentioning (though I
> don't feel strongly) that GIT_TRACE_PACK works with or without
> GIT_TRACE_PACKET - that wasn't immediately obvious to me, but it makes
> sense once I read the code.
>
> Thanks!
Thanks, both. I think this series makes sense.
As to the documentation, I have a feeling that, unless the reader
and/or the user intimately knows that TRACE_PACK is implemented by
hooking into the same mechanism that TRACE_PACKET needs to, s/he
would not even wonder if TRACE_PACKET needs to be enabled when
asking for TRACE_PACK. Yes, one is a proper substring of the other,
but the similarity between the two stops there. While I do not
think it would hurt very much to mention that they are independent,
I have a slight suspicion that it might make it more likely to get
user confused.
next prev parent reply other threads:[~2015-06-16 16:39 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGZ79kaS4utvDbXOo7emmSUH6M-8LY-oA65Ss3PLDkFModkbSg@mail.gmail.com>
2015-06-11 18:59 ` [PATCH v2] fetch-pack: optionally save packs to disk Augie Fackler
2015-06-12 6:22 ` Johannes Sixt
2015-06-12 15:07 ` Junio C Hamano
2015-06-12 17:02 ` Augie Fackler
2015-06-12 18:00 ` Jeff King
2015-06-12 21:25 ` Jeff King
2015-06-12 21:28 ` [PATCH 1/3] pkt-line: simplify starts_with checks in packet tracing Jeff King
2015-06-12 21:35 ` Stefan Beller
2015-06-12 21:28 ` [PATCH 2/3] pkt-line: tighten sideband PACK check when tracing Jeff King
2015-06-12 21:39 ` Stefan Beller
2015-06-12 21:41 ` Jeff King
2015-06-12 21:43 ` Stefan Beller
2015-06-12 21:28 ` [PATCH 3/3] pkt-line: support tracing verbatim pack contents Jeff King
2015-06-16 15:38 ` Augie Fackler
2015-06-16 16:39 ` Junio C Hamano [this message]
2015-06-16 16:43 ` Jeff King
2015-06-16 16:52 ` Augie Fackler
2015-06-16 17:23 ` Jeff King
2015-06-16 17:10 ` Jeff King
2015-06-16 17:14 ` Augie Fackler
2015-06-16 17:18 ` Jeff King
2015-06-16 17:23 ` Augie Fackler
2015-06-16 19:31 ` [PATCH/RFC 0/3] add GIT_TRACE_STDIN Jeff King
2015-06-16 19:35 ` [PATCH 1/3] trace: implement %p placeholder for filenames Jeff King
2015-06-16 19:36 ` [PATCH 2/3] trace: add pid to each output line Jeff King
2015-06-16 19:37 ` [PATCH 3/3] trace: add GIT_TRACE_STDIN Jeff King
2015-06-16 19:49 ` Jeff King
2015-06-16 21:20 ` Jeff King
2015-06-17 10:04 ` Duy Nguyen
2015-06-17 19:10 ` Jeff King
2015-06-18 10:20 ` Duy Nguyen
2015-06-26 18:47 ` Junio C Hamano
2015-06-12 16:54 ` [PATCH v2] fetch-pack: optionally save packs to disk Augie Fackler
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=xmqqvben6214.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=augie@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=j6t@kdbg$(echo .)org \
--cc=peff@peff$(echo .)net \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox