git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Toon Claes <toon@iotcl.com>
Cc: git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH 01/14] progress: stop using `the_repository`
Date: Tue, 7 Jan 2025 08:19:33 +0100	[thread overview]
Message-ID: <Z3zVhZC437Kx60dm@pks.im> (raw)
In-Reply-To: <87v7urk6dl.fsf@iotcl.com>

On Mon, Jan 06, 2025 at 09:57:26PM +0100, Toon Claes wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Stop using `the_repository` in the "progress" subsystem by passing in a
> > repository when initializing `struct progress`. Furthermore, store a
> > pointer to the repository in that struct so that we can pass it to the
> > trace2 API when logging information.
> >
> > Adjust callers accordingly by using `the_repository`. While there may be
> > some callers that have a repository available in their context, this
> > trivial conversion allows for easier verification and bubbles up the use
> > of `the_repository` by one level.
> 
> I'm not sure I agree here. Below I've marked all places where I think we
> are able to get the repo from somewhere else than `the_repository`. For
> example, looking at diffcore-rename.c, the already present calls to
> trace2_*() use `options->repo`, why shouldn't we do the same?
> 
> I understand what your angle is, you want to bubble up `the_repository`
> and make the changes easier to reason about, but it feels to me we're
> creating extra work. If most people disagree with me, I'm happy to take
> your approach.

The problem is that this could lead to a change in behaviour, as the repo
we have available may or may not be the same as `the_repository`. So
without auditing every single callsite I have no way of knowing, and
that audit is quite involved when it touches a lot of subsystems at
once.

That's why I'm instead pushing it further down the road: we know that
injecting `the_repository` will yield the exact same behaviour as
before, and we only need to audit a single subsystem, namely the one
that we're currently converting. So it's one more step overall, but by
separating mechanical from non-mechanical changes it makes the steps
simpler overall.

Patrick

  reply	other threads:[~2025-01-07  7:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-17  6:43 [PATCH 00/14] Stop using `the_repository` in some trivial cases Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 01/14] progress: stop using `the_repository` Patrick Steinhardt
2024-12-31  6:42   ` Karthik Nayak
2025-01-06 20:57   ` Toon Claes
2025-01-07  7:19     ` Patrick Steinhardt [this message]
2024-12-17  6:43 ` [PATCH 02/14] pager: " Patrick Steinhardt
2024-12-17 12:17   ` shejialuo
2024-12-31  6:55     ` Karthik Nayak
2024-12-17  6:43 ` [PATCH 03/14] trace: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 04/14] serve: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 05/14] send-pack: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 06/14] server-info: " Patrick Steinhardt
2024-12-17 12:31   ` shejialuo
2024-12-17  6:43 ` [PATCH 07/14] diagnose: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 08/14] mailinfo: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 09/14] credential: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 10/14] resolve-undo: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 11/14] tmp-objdir: " Patrick Steinhardt
2024-12-17  6:43 ` [PATCH 12/14] add-interactive: " Patrick Steinhardt
2024-12-17  6:44 ` [PATCH 13/14] graph: " Patrick Steinhardt
2024-12-17  6:44 ` [PATCH 14/14] match-trees: " Patrick Steinhardt
2024-12-17 12:45 ` [PATCH 00/14] Stop using `the_repository` in some trivial cases shejialuo
2024-12-27 14:26   ` Patrick Steinhardt
2025-01-07 11:41 ` Karthik Nayak
2025-01-07 21:12   ` Toon Claes
2025-01-07 21:15     ` Junio C Hamano

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=Z3zVhZC437Kx60dm@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=toon@iotcl.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 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 NNTP newsgroup(s).