From: Junio C Hamano Date: Tue, 31 Mar 2026 20:27:57 GMT Subject: Re: [PATCH] unpack-trees: use explicit repository in trace2 calls Message-ID: In-Reply-To: Junio C Hamano writes: > Patrick Steinhardt 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.