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

Reply via email to