Re: Bug in 2.48 with `git refs migrate`

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

 



On 2025-01-15 at 11:54:51, Karthik Nayak wrote:
> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

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