Re: Bug in 2.48 with `git refs migrate`
- From
Karthik Nayak <karthik.188@gmail.com>
- Date
- Jan 16, 2025, 07:29 UTC
- Message-ID
- <CAOLa=ZS2ZQRSbirW1HLYJ1d1HAwmfugKdNGBCNGtS-yS1rcKEA@mail.gmail.com>
- In-Reply-To
- <Z4hpXwtv-ChwAGeG@tapette.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 38 quoted lines
> On 2025-01-15 at 11:54:51, Karthik Nayak wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>>
>> I'm attaching a patch below which should fixes the issue for me and also
>> adding a test to test against the same. I'd be grateful if you could
>> also test the patch against the repositoryies you mention.
>
> Fantastic, I'll try to do that tomorrow and get back to you. I really
> appreciate such a prompt response.
>
>> diff --git a/refs/refs-internal.h b/refs/refs-internal.h
>> index 16550862d3..aaab711bb9 100644
>> --- a/refs/refs-internal.h
>> +++ b/refs/refs-internal.h
>> @@ -203,6 +203,7 @@ struct ref_transaction {
>> enum ref_transaction_state state;
>> void *backend_data;
>> unsigned int flags;
>> + unsigned int max_index;
>> };
>>
>> /*
>> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
>> index 00d95a9a2f..289496058e 100644
>> --- a/refs/reftable-backend.c
>> +++ b/refs/reftable-backend.c
>> @@ -942,6 +942,7 @@ struct write_transaction_table_arg {
>> size_t updates_nr;
>> size_t updates_alloc;
>> size_t updates_expected;
>> + unsigned int max_index;
>
> I wonder if this and the above should be `uint64_t` instead of `unsigned
> int`. From the file names and the data format, it looks like we
> intentionally use a 64-bit integer. That's good, because I have
> unfortunately seen some people who have created giant test repositories
> with really unreasonable numbers of commits and I could see us possibly
> exceeding a 32-bit integer here.Ideally it should be okay, since this only comes into play when we're migrating reflogs. So the index would be the number of reflog entries for a given ref. I suppose even for large repositories this number should be low. But I'd rather be safe here, so let me modify this in the next version to be 'uint64_t'.
> -- > brian m. carlson (they/them or he/him) > Toronto, Ontario, CA