Re: Bug in 2.48 with `git refs migrate`

"brian m. carlson" [off-list ref] writes:

On 2025-01-15 at 11:54:51, Karthik Nayak wrote:

quoted

"brian m. carlson" [off-list ref] 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.

quoted

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