Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > +static int write_oid(const struct object_id *oid, struct packed_git *pack, > + uint32_t pos, void *data) > +{ > + int fd = *(int *)data; > + > + xwrite(fd, oid_to_hex(oid), GIT_SHA1_HEXSZ); > + xwrite(fd, "\n", 1); > + return 0; > +} > + > +static void repack_promisor_objects(const struct packed_objects_args *args, > + struct string_list *names) > +{ > + struct child_process cmd = CHILD_PROCESS_INIT; > + FILE *out; > + struct strbuf line = STRBUF_INIT; > + > + prepare_packed_objects(&cmd, args); > + cmd.in = -1; > + > + if (start_command(&cmd)) > + die("Could not start pack-objects to repack promisor objects"); > + > + for_each_packed_object(write_oid, &cmd.in, > + FOR_EACH_OBJECT_PROMISOR_ONLY); > + close(cmd.in); for_each_object_in_pack() is a fine way to make sure that you list everythning in a pack, but I suspect it is a horrible way to feed a list of objects to pack-objects, as it goes by the .idx order, which is by definition a way to enumerate objects in a randomly useless order. Do we already have an access to the in-core reverse index for the pack at this point in the code? If so, we can enumerate the objects in the offset order without incurring a lot of cost (building the in-core revindex is the more expensive part). When writing a pack, we try to make sure that related objects are written out close to each other [*1*], so listing them in the offset order (with made-up pathname information to _force_ that objects that live close together in the original pack are grouped together by getting similar names) might give us a better than horrible deltification. I dunno. Side note *1*: "related" has two axis, and one is relevant for better deltification, while the other is not useful. The one I have in mind here is that we write set of blobs that belong to the same "delta family" together. I do not think such a "make it a bit better than horrible" is necessary in an initial version, but it deserves an in-code NEEDSWORK comment to remind us that we need to measure and experiment. Thanks.