git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Han-Wen Nienhuys <hanwen@google.com>
To: git <git@vger.kernel.org>
Subject: Fwd: [PATCH] RFC: refs: add GIT_DEBUG_REFS debugging mechanism
Date: Thu, 3 Sep 2020 12:10:32 +0200	[thread overview]
Message-ID: <CAFQ2z_P9dRKX-O3MGFWj1TaYciCLHBboP0jAvROYyn5QaPngYw@mail.gmail.com> (raw)
In-Reply-To: <CAFQ2z_M_2mmL1LXcgR5cv3Ac1AJ363jaejZz3p6AcV6b3DftTQ@mail.gmail.com>

On Thu, Sep 3, 2020 at 8:19 AM Jeff King <peff@peff.net> wrote:
>
> > - if this is only going to be used for tests and for ad hoc debugging,
> >   I'd suggest sticking to the simple trace_key based unstructured
> >   tracing API
>
> Yeah, from my look at the debug patch, this seems sensible.


thanks, I'll rework it to use the traditional trace API.

> As clever as the "debug" ref-backend wrapper object is, I also wonder if
> it might be simpler to just add trace calls to all of the outer
> functions (e.g., ref_transaction_prepare(), etc). Unlike a "real" OO
> system, we're not typically passing around the polymorphic ref_store
> type, but always access it through those type-agnostic wrappers. But
> maybe that would end up just as long. I dunno.

The ref backend supports callbacks, so it will always require some
amount of wrapping. The advantage of this approach is that the debug
support stays very neatly separate from the actual logic, and that the
compiler enforces that we add debug support if a new ref backend
method is added.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado



-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.

  parent reply	other threads:[~2020-09-03 10:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-28 15:28 [PATCH] RFC: refs: add GIT_DEBUG_REFS debugging mechanism Han-Wen Nienhuys via GitGitGadget
2020-09-02 17:49 ` Jonathan Tan
2020-09-03  5:44   ` Jonathan Nieder
2020-09-03  6:19     ` Jeff King
     [not found]       ` <CAFQ2z_M_2mmL1LXcgR5cv3Ac1AJ363jaejZz3p6AcV6b3DftTQ@mail.gmail.com>
2020-09-03 10:10         ` Han-Wen Nienhuys [this message]
2020-09-07 15:24 ` [PATCH v2] refs: add GIT_TRACE_REFS " Han-Wen Nienhuys via GitGitGadget
2020-09-08 21:15   ` Junio C Hamano
2020-09-09  9:43     ` Han-Wen Nienhuys
2020-09-09 10:15   ` [PATCH v3] " Han-Wen Nienhuys via GitGitGadget
2020-09-16 15:53     ` [PATCH v4] " Han-Wen Nienhuys via GitGitGadget

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CAFQ2z_P9dRKX-O3MGFWj1TaYciCLHBboP0jAvROYyn5QaPngYw@mail.gmail.com \
    --to=hanwen@google.com \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).