> But what to delta against what else is determined by the pathname
> info, which is now lost by enumerating objects without tree/history
> walking. By giving phoney pathnames to objects while enumerating
> them in offset order and giving similar pathnames to objects closer
> to each other, I was
Jonathan Tan writes:
>> Just a note (and a request-for-sanity-check) and not meant to be a
>> request to update the code, but with a still-in-pu 4b757a40 ("Use
>> remote_odb_get_direct() and has_remote_odb()", 2018-08-02) in
>> flight, repository_format_partial_clone is now gone.
>> ...
> Thanks
Jeff King writes:
> I think that the for_each_packed_object() interface should visit items
> in pack order.
Yeah, that may make more sense. Any order is more logical than the
object name order (which by definition is random, so useful only
when you want them in a random order), and pack order
On Tue, Aug 07, 2018 at 04:23:04PM -0700, Jonathan Tan wrote:
> > Do we already have an access to the in-core reverse index for the
> > pack at this point in the code?
>
> As far as I can tell, no. These patches construct the list of promisor
> objects in repack.c (which does not use the
Jonathan Tan writes:
>> 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
> Just a note (and a request-for-sanity-check) and not meant to be a
> request to update the code, but with a still-in-pu 4b757a40 ("Use
> remote_odb_get_direct() and has_remote_odb()", 2018-08-02) in
> flight, repository_format_partial_clone is now gone.
>
> I've tentatively resolved the above
> 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.
That's
Jonathan Tan writes:
> @@ -293,6 +346,9 @@ int cmd_repack(int argc, const char **argv, const char
> *prefix)
> if (pack_everything & ALL_INTO_ONE) {
> get_non_kept_pack_filenames(_packs, _pack_list);
>
> + if (repository_format_partial_clone)
> +
Jonathan Tan 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;
> +}
> +
>
Currently, repack does not touch promisor packfiles at all, potentially
causing the performance of repositories that have many such packfiles to
drop. Therefore, repack all promisor objects if invoked with -a or -A.
This is done by an additional invocation of pack-objects on all promisor
objects
10 matches
Mail list logo
