From: "René Scharfe" <l.s.r@web•de>
To: Elijah Newren <newren@gmail•com>
Cc: Git List <git@vger•kernel.org>
Subject: Re: [PATCH] xdiff-interface: stop using the_repository
Date: Sun, 15 Feb 2026 19:42:42 +0100 [thread overview]
Message-ID: <97e0fa77-0946-4898-b721-5f1a5d1153bd@web.de> (raw)
In-Reply-To: <CABPp-BFuwvqiCTCCpoyT6em9_1-qrgPWHWhrufQ3UuZ+Kfkb6A@mail.gmail.com>
On 2/9/26 7:57 PM, Elijah Newren wrote:
> On Sun, Feb 8, 2026 at 5:47 AM René Scharfe <l.s.r@web•de> wrote:
>>
> ...
>> diff --git a/merge-ort.c b/merge-ort.c
>> index e80e4f735a..a4103d56ed 100644
>> --- a/merge-ort.c
>> +++ b/merge-ort.c
>> @@ -2136,9 +2136,9 @@ static int merge_3way(struct merge_options *opt,
>> name2 = mkpathdup("%s:%s", opt->branch2, pathnames[2]);
>> }
>>
>> - read_mmblob(&orig, o);
>> - read_mmblob(&src1, a);
>> - read_mmblob(&src2, b);
>> + read_mmblob(&orig, the_repository->objects, o);
>> + read_mmblob(&src1, the_repository->objects, a);
>> + read_mmblob(&src2, the_repository->objects, b);
>>
>> merge_status = ll_merge(result_buf, path, &orig, base,
>> &src1, name1, &src2, name2,
>
> A minor point, but could we use opt->repo instead of the_repository in
> merge-ort?
>
> I've cleaned out all the_repository references before, except one in
> prefetch_for_content_merges(), and would prefer folks not add more.
I can imagine that this whack-a-mole game is annoying. The patch above
at least didn't actually add them, it just made them explicit. Indirect
references may look better on the surface, but the functions that
contain them still can only be used with the_repository.
The only way I can see to avoid that pain would be to convert leaf
functions, only, i.e. those that reference the_repository and friends,
but don't call any other functions or macros that do. This way a
transition to the_repository-free would be meaningful and permanent for
each function.
Converting on all levels of the call chain in parallel requires less
coordination and is probably more realistic in our distributed
development model, though.
Do you (anyone) know nice tools for listing the full call chain graph
of C functions? cscope can probably be made to do that with some
scripting, but seems inefficient for that purpose. Such a tool could
be used to check for indirect references and tell us if functions are
safe for use with other repositories.
René
next prev parent reply other threads:[~2026-02-15 18:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-08 13:47 [PATCH] xdiff-interface: stop using the_repository René Scharfe
2026-02-09 9:48 ` Patrick Steinhardt
2026-02-09 14:14 ` René Scharfe
2026-02-09 11:15 ` Junio C Hamano
2026-02-09 15:21 ` René Scharfe
2026-02-09 17:45 ` Junio C Hamano
2026-02-09 19:24 ` René Scharfe
2026-02-09 18:57 ` Elijah Newren
2026-02-09 20:01 ` Junio C Hamano
2026-02-15 18:42 ` René Scharfe
2026-02-15 18:42 ` René Scharfe [this message]
2026-02-09 19:24 ` [PATCH v2] " René Scharfe
2026-02-10 13:28 ` Patrick Steinhardt
2026-02-10 21:31 ` 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=97e0fa77-0946-4898-b721-5f1a5d1153bd@web.de \
--to=l.s.r@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=newren@gmail$(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