On Wed, Dec 02 2020, Junio C Hamano wrote: > 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. Hi. Just a quick note to say thanks for all the feedback, and that I don't have a v3 ready now, but will submit one soon-ish. FWIW the header-body newline thing wasn't something I was trying to sneak in, I went wrong in my testing somewhere and thought it was a bug under mktag. Will test for that, remove that check or whatever as appropriate. Thanks for the review.
