On Mon, 9 Sep 2013, Duy Nguyen wrote:
> On Sun, Sep 8, 2013 at 10:04 PM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> wrote:
> > +static void prepare_sha1_table(void)
> > +{
> > + unsigned i;
> > + /*
> > + * This table includes SHA-1s that may not be present in the
> > + * pack. One of the use of such SHA-1 is for completing thin
> > + * packs, where index-pack does not need to add SHA-1 to the
> > + * table at completion time.
> > + */
> > + v4.all_objs = xmalloc(nr_objects * sizeof(*v4.all_objs));
> > + v4.all_objs_nr = nr_objects;
> > + for (i = 0; i < nr_objects; i++)
> > + v4.all_objs[i] = objects[i].idx;
> > + qsort(v4.all_objs, nr_objects, sizeof(*v4.all_objs),
> > + sha1_idx_sort);
> > +}
> > +
>
> fwiw this is wrong. Even in the non-thin pack case, pack-objects could
> write multiple packs to disk and we need different sha-1 table for
> each one. The situation is worse for thin pack because not all
> preferred_base entries end up a real dependency in the final pack. I'm
> working on it..
Is anyone still using --max-pack-size ?
I'm wondering if producing multiple packs from pack-objects is really
useful these days. If I remember correctly, this was created to allow
the archiving of large packs onto CDROMs or the like.
I'd be tempted to simply ignore this facility and get rid of its
complexity if no one uses it. Or assume that split packs will have
inter dependencies. Or they will be pack v2 only.
Nicolas