From: Karthik Nayak <karthik.188@gmail.com>
Date: Wed, 29 Jul 2026 22:53:27 GMT
Subject: Re: [PATCH GSoC 2/5] fetch-object-info: parse type from server response
Message-ID: <CAOLa=ZSdh8EeikBfTn58sNpfSQ=M2VwE5eA25c2ckQYhx6wjBQ@mail.gmail.com>
In-Reply-To: <CAOLa=ZQbf2vdYOkFBHQ2Kkk=Yc0uSZXEPy+FQPyzp9C8=sUFEQ@mail.gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

>> @@ -148,6 +154,10 @@ int fetch_object_info(const enum protocol_version version, struct object_info_ar
>>  			    object_info_values.items[0].string,
>>  			    object_info_values.items[size_index + 1].string);
>>
>> +		if (type_index >= 0)
>> +			*object_info_data[i].typep =
>> +				type_from_string(object_info_values.items[type_index + 1].string);
>> +
>
> For size, passing the value as a number makes sense, since the value
> represents the field directly.
>
> For type however, we're passing in a value, while the actual field is a
> string. We rely on `type_from_string()` to make that translation for us,
> which internatlly depends on `object_type_strings[]`. What if there is a
> mismatch between the server and the client? Shouldn't we be sending in
> the string itself?
>
>>  		string_list_clear(&object_info_values, 0);
>>  	}
>>  	check_stateless_delimiter(stateless_rpc, reader, "stateless delimiter expected");
>>
>> --
>> 2.54.0

Ah! We do send in the string itself, all good here :)