Re: [PATCH v3 9/9] midx: add repository to `multi_pack_index` struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Taylor Blau <me@xxxxxxxxxxxx> writes:

> On Wed, Oct 30, 2024 at 03:32:34PM +0100, Karthik Nayak wrote:
>> The `multi_pack_index` struct represents the MIDX for a repository.
>> Here, we add a pointer to the repository in this struct, allowing direct
>> use of the repository variable without relying on the global
>> `the_repository` struct.
>>
>> With this addition, we can determine the repository associated with a
>> `bitmap_index` struct. A `bitmap_index` points to either a `packed_git`
>> or a `multi_pack_index`, both of which have direct repository
>> references. To support this, we introduce a static helper function,
>> `bitmap_repo`, in `pack-bitmap.c`, which retrieves a repository given a
>> `bitmap_index`.
>>
>> With this, we clear up all usages of `the_repository` within
>> `pack-bitmap.c` and also remove the `USE_THE_REPOSITORY_VARIABLE`
>> definition. Bringing us another step closer to remove all global
>> variable usage.
>>
>> Although this change also opens up the potential to clean up `midx.c`,
>> doing so would require additional refactoring to pass the repository
>> struct to functions where the MIDX struct is created: a task better
>> suited for future patches.
>>
>> Signed-off-by: Karthik Nayak <karthik.188@xxxxxxxxx>
>> ---
>>  midx.c        |  1 +
>>  midx.h        |  3 ++
>>  pack-bitmap.c | 97 +++++++++++++++++++++++++++++++--------------------
>>  3 files changed, 64 insertions(+), 37 deletions(-)
>>
>> diff --git a/midx.c b/midx.c
>> index 8edb75f51d..7a34473010 100644
>> --- a/midx.c
>> +++ b/midx.c
>> @@ -131,6 +131,7 @@ static struct multi_pack_index *load_multi_pack_index_one(const char *object_dir
>>  	m->data = midx_map;
>>  	m->data_len = midx_size;
>>  	m->local = local;
>> +	m->r = the_repository;
>
> Same note here about calling this 'r' rather than 'repo'.
>

My bad, I'll fix it in the next version.

> I do wonder if it creates any awkwardness to have the_repository
> assigned here unconditionally when we do specify the object_dir. I think
> it's OK so long as we don't start replacing 'm->object_dir' with
> 'm->repo->objects->odb->path'.
>
>> @@ -1980,18 +1997,23 @@ struct bitmap_index *prepare_bitmap_walk(struct rev_info *revs,
>>  	if (!use_boundary_traversal)
>>  		object_array_clear(&revs->pending);
>>
>> +	repo = bitmap_repo(bitmap_git);
>> +
>>  	if (haves) {
>> -		if (use_boundary_traversal) {
>> -			trace2_region_enter("pack-bitmap", "haves/boundary", the_repository);
>> +		if (use_boundary_traversal)
>> +		{
>> +			trace2_region_enter("pack-bitmap", "haves/boundary", repo);
>>  			haves_bitmap = find_boundary_objects(bitmap_git, revs, haves);
>> -			trace2_region_leave("pack-bitmap", "haves/boundary", the_repository);
>> -		} else {
>> -			trace2_region_enter("pack-bitmap", "haves/classic", the_repository);
>> +			trace2_region_leave("pack-bitmap", "haves/boundary", repo);
>> +		}
>> +		else
>> +		{
>> +			trace2_region_enter("pack-bitmap", "haves/classic", repo);
>>  			revs->ignore_missing_links = 1;
>>  			haves_bitmap = find_objects(bitmap_git, revs, haves, NULL);
>>  			reset_revision_walk();
>>  			revs->ignore_missing_links = 0;
>> -			trace2_region_leave("pack-bitmap", "haves/classic", the_repository);
>> +			trace2_region_leave("pack-bitmap", "haves/classic", repo);
>>  		}
>
> Odd braces?
>

Indeed. Will fix this too.

> Thanks,
> Taylor

Thanks for the review.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux