Re: [PATCH v6 00/11] nd/pack-objects-pack-struct updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 21, 2018 at 5:53 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> That's going to be super rare (and probably nonexisting) edge case, but
>> (untested) I wonder if something like this on top would alleviate your
>> concerns, i.e. instead of dying we just take the first N packs up to our
>> limit:
>>
>>     diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
>>     index 4406af640f..49d467ab2a 100644
>>     --- a/builtin/pack-objects.c
>>     +++ b/builtin/pack-objects.c
>>     @@ -1065,8 +1065,9 @@ static int want_object_in_pack(const struct object_id *oid,
>>
>>             want = 1;
>>      done:
>>     -       if (want && *found_pack && !(*found_pack)->index)
>>     -               oe_add_pack(&to_pack, *found_pack);
>>     +       if (want && *found_pack && !(*found_pack)->index) {
>>     +               if (oe_add_pack(&to_pack, *found_pack) == -1)
>>     +                       return 0;
>>
>>             return want;
>>      }
>
> It is probably a small first step in the right direction, but we'd
> need to communicate which packs we ignored with this logic to the
> calling program.  I offhand do not know how we would handle the "-d"
> part of "repack -a -d" without it.

repack will delete all the packs except ones with .keep files and ones
created by pack-objects. So this change alone is not enough. I think I
did mention that we could make this work by making repack run
pack-objects multiple times. But I did not do it because I did not
think it could really happen.
-- 
Duy




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux