Re: [PATCH v2 00/10] make "mktag" use fsck_tag()

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

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> On Thu, Nov 26 2020, Ævar Arnfjörð Bjarmason wrote:
>>
>>> Now a non-RFC. I went for the approach I suggested in
>>> <87r1ognv4b.fsf@xxxxxxxxxxxxxxxxxxx> of just having fsck_tag() able to
>>> optionally tell us about its parsed tag/type, thus avoiding any need
>>> for a custom parser in mktag.c. Hopefully I've addressed the rest of
>>> the feedback, range-diff below.
>>
>> Ping @ Jeff & brian: you said you wanted this in one shape or another,
>> so mind seeing if the v2 looks good to you?:)
>>
>> Junio didn't pick it up for the "What's Cooking" sent out recently,
>> hopefully some reviewer ACK/NACK will help move it forward. Thanks!
>
> True.  I don't want to queue too many topics on 'seen', only to end
> up with a pile of patches that haven't been reviewed adequately and
> cannot move forward.

So, now I've seen all of them.

There were some minor things in the earlier part I commented on, and
if I am not mistaken, a new check, "body must not begin with a blank
line", should not be added at all, which would affect 08/10.

I am not sure how much longer we want to retain the .extra level of
checks that are more strict than those of fsck.  If we decide that
it is not worth it to forbid new object headers, we may be able to
lose 08/10 altogether.

Other than the above, the series mostly looked well done.

Thanks.




[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