Re: [PATCH v4 4/4] sha1_name: minimize OID comparisons during disambiguation

> On Sun, Oct 08, 2017 at 02:49:42PM -0400, Derrick Stolee wrote:
>
>> @@ -505,6 +506,65 @@ static int extend_abbrev_len(const struct object_id *oid, void *cb_data)
>>   	return 0;
>>   }
>>   
>> +static void find_abbrev_len_for_pack(struct packed_git *p,
>> +				     struct min_abbrev_data *mad)
>> +{
>> +	int match = 0;
>> +	uint32_t num, last, first = 0;
>> +	struct object_id oid;
>> +
>> +	open_pack_index(p);
>> +	num = p->num_objects;
>> +	last = num;
>> +	while (first < last) {
>> [...]
> Your cover letter lists:
>
>    * Silently skip packfiles that fail to open with open_pack_index()
>
> as a change from the previous version. But this looks the same as the
> last round. I think this _does_ end up skipping such packfiles because
> p->num_objects will be zero. Is it worth having a comment to that
> effect (or even just an early return) to make it clear that the
> situation is intentional?
>
> Although...
>
>> +	/*
>> +	 * first is now the position in the packfile where we would insert
>> +	 * mad->hash if it does not exist (or the position of mad->hash if
>> +	 * it does exist). Hence, we consider a maximum of three objects
>> +	 * nearby for the abbreviation length.
>> +	 */
>> +	mad->init_len = 0;
>> +	if (!match) {
>> +		nth_packed_object_oid(&oid, p, first);
>> +		extend_abbrev_len(&oid, mad);
> If we have zero objects in the pack, what would nth_packed_object_oid()
> be returning here?
>
> So I actually think we do want an early return, not just when
> open_packed_index() fails, but also when p->num_objects is zero.
>
> -Peff