From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Karthik Nayak <karthik.188@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 03/16] refs: implement releasing ref storages
Date: Fri, 17 May 2024 09:09:21 +0200 [thread overview]
Message-ID: <ZkcCoY8_S2nSXSyU@tanuki> (raw)
In-Reply-To: <xmqqjzjtr602.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On Thu, May 16, 2024 at 11:01:01AM -0700, Junio C Hamano wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
> >> +static void debug_release(struct ref_store *refs)
> >> +{
> >> + struct debug_ref_store *drefs = (struct debug_ref_store *)refs;
> >
> > We should probably add a trace here, using `trace_printf_key()`
>
> A totally ignorant question. Should we be adding more traces with
> trace_* API instead of trace2_* API? If the latter aims to cover
> superset of use cases the former did, I was hoping that we can
> eventually deprecate the former, hence this question. Of course We
> could add a compatiblity layer that emulates trace_* API with a thin
> wrapper around trace2_* API, but if we do not add new callers, it
> may still be feasible to directly migrate the callers to use trace2_
> API without having to invent such compatibility wrappers.
I cannot really answer this question as I ain't got much of a clue
around the tracing APIs. But in this case I think we should indeed add
this via `trace_printf_key()` so that we remain consistent with all the
other wrappers in the debug store. I'd argue that either all functions
here should use trace or trace2, but not a mixture.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-05-17 7:09 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 8:04 [PATCH 00/16] refs: drop all references to `the_repository` Patrick Steinhardt
2024-05-16 8:04 ` [PATCH 01/16] refs: adjust names for `init` and `init_db` callbacks Patrick Steinhardt
2024-05-16 14:50 ` Karthik Nayak
2024-05-16 8:04 ` [PATCH 02/16] refs: rename `init_db` callback to avoid confusion Patrick Steinhardt
2024-05-16 15:00 ` Karthik Nayak
2024-05-16 18:24 ` Junio C Hamano
2024-05-17 7:08 ` Patrick Steinhardt
2024-05-16 8:04 ` [PATCH 03/16] refs: implement releasing ref storages Patrick Steinhardt
2024-05-16 16:39 ` Karthik Nayak
2024-05-16 18:01 ` Junio C Hamano
2024-05-17 7:09 ` Patrick Steinhardt [this message]
2024-05-17 7:08 ` Patrick Steinhardt
2024-05-16 8:04 ` [PATCH 04/16] refs: track ref stores via strmap Patrick Steinhardt
2024-05-16 18:34 ` Junio C Hamano
2024-05-16 8:04 ` [PATCH 05/16] refs: pass repo when retrieving submodule ref store Patrick Steinhardt
2024-05-16 18:44 ` Junio C Hamano
2024-05-17 7:09 ` Patrick Steinhardt
2024-05-16 8:04 ` [PATCH 06/16] refs: refactor `resolve_gitlink_ref()` to accept a repository Patrick Steinhardt
2024-05-16 18:45 ` Junio C Hamano
2024-05-16 8:04 ` [PATCH 07/16] refs: retrieve worktree ref stores via associated repository Patrick Steinhardt
2024-05-16 8:04 ` [PATCH 08/16] refs: convert iteration over replace refs to accept ref store Patrick Steinhardt
2024-05-16 8:04 ` [PATCH 09/16] refs: pass ref store when detecting dangling symrefs Patrick Steinhardt
2024-05-16 8:04 ` [PATCH 10/16] refs: move object peeling into "object.c" Patrick Steinhardt
2024-05-16 20:55 ` Junio C Hamano
2024-05-16 8:05 ` [PATCH 11/16] refs: pass repo when peeling objects Patrick Steinhardt
2024-05-16 8:05 ` [PATCH 12/16] refs: drop `git_default_branch_name()` Patrick Steinhardt
2024-05-16 18:44 ` Karthik Nayak
2024-05-16 8:05 ` [PATCH 13/16] refs: remove `dwim_log()` Patrick Steinhardt
2024-05-16 8:05 ` [PATCH 14/16] refs/files: use correct repository Patrick Steinhardt
2024-05-16 8:05 ` [PATCH 15/16] refs/files: remove references to `the_hash_algo` Patrick Steinhardt
2024-05-16 8:05 ` [PATCH 16/16] refs/packed: " Patrick Steinhardt
2024-05-16 18:57 ` [PATCH 00/16] refs: drop all references to `the_repository` Karthik Nayak
2024-05-17 7:08 ` Patrick Steinhardt
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=ZkcCoY8_S2nSXSyU@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karthik.188@gmail.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.