Re: [PATCH 08/11] pack-objects: create pack v4 tables
Nicolas Pitre writes: > 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 thought this was more about using a packfile on smaller (e.g. 32-bit) systems, but I may be mistaken. 2b84b5a8 (Introduce the config variable pack.packSizeLimit, 2008-02-05) mentions "filesystem constraints": Introduce the config variable pack.packSizeLimit "git pack-objects" has the option --max-pack-size to limit the file size of the packs to a certain amount of bytes. On platforms where the pack file size is limited by filesystem constraints, it is easy to forget this option, and this option does not exist for "git gc" to begin with. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/11] pack-objects: create pack v4 tables
On Mon, 9 Sep 2013, Duy Nguyen wrote:
> On Sun, Sep 8, 2013 at 10:04 PM, Nguyễn Thái Ngọc Duy
> 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
Re: [PATCH 08/11] pack-objects: create pack v4 tables
On Sun, Sep 8, 2013 at 10:04 PM, Nguyễn Thái Ngọc Duy 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..
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
