Re: [PATCH] unpack-trees: use explicit repository in trace2 calls

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2026, 20:27 UTC
Message-ID: <xmqqjyurzquq.fsf@gitster.g>
In-Reply-To: <xmqqy0j82ex8.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 21 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
>
>> The changes in `unpack_trees()` are a bit misleading -- while it reads
>> as if we don't use `the_repository` anymore, we still do because the
>> function starts with:
>>
>>   int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options *o)
>>   {
>>   	struct repository *repo = the_repository;
>>
>> So would it make sense to maybe have a separate patch where we inject a
>> repository as a parameter to `unpack_trees()`?
>
> We can see that "struct unpack_trees_options" is rich enough in the
> merge context that it would be a natural place to have it unless it
> is already tehre.
>
> In fact, o->dst_index->repo should probably be what you want, and
> because it would be insane to start from an index in a repo and
> store the resulting updated index in another repo, there probably
> needs an assert(o->dst_index->repo == o->src_index->repo) somewhere.

Actually, assert(dst_index->repo == src_index->repo) is probably not what we want, as dst_index can legitimately be NULL, even since 34110cd4 (Make 'unpack_trees()' have a separate source and destination index, 2008-03-06) introduced srparete src/dst indices to unpack_trees() API.

    We will always unpack into our own internal index, but we will take the
    source from wherever specified, and we will optionally write the result
    to a specified index (optionally, because not everybody even _wants_ any
    result: the index diffing really wants to just walk the tree and index
    in parallel).

So o->src_index->repo is what we want in this case, I think.