From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id A0A971F86C for ; Tue, 1 Dec 2020 20:35:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730567AbgLAUdz (ORCPT ); Tue, 1 Dec 2020 15:33:55 -0500 Received: from pb-smtp21.pobox.com ([173.228.157.53]:63792 "EHLO pb-smtp21.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727165AbgLAUdy (ORCPT ); Tue, 1 Dec 2020 15:33:54 -0500 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id E4E45114B76; Tue, 1 Dec 2020 15:33:12 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=oQ1Soup2vLJr 5jcbdc1QbHH12Xg=; b=IhdxrcpM3Ak8SD1UodQNQdkgYml3qJjKYlCNJ15AIn4C zgEx08x5i00hjmX3VY5cHS9o8XDzoy2djzSLUV0EWNndRCwp2xtg6oylMTJoH7Bf Ja6yUIyG7gifrsHrDALALuqZP0TYOUlpFPmemOnv4jS0QUbrSAvB0J2gsYdTEQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=ha0DNE IDfBwLFw8eGcE9rUfL+5e112B7jDMEupU241z+6ubumf1gry78Vuraq8FLZYpzyf 8LnadylUAGqrOqBENPJDg8yLyvIEtnhOaoZArpr5CRWUf0ZIs4xQ7/E40ynY4cHf SFQI0XCtsS8M5Z7dI20fWTZvpeQ+DscH0AZsY= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id DCED0114B75; Tue, 1 Dec 2020 15:33:12 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 274FA114B74; Tue, 1 Dec 2020 15:33:10 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: git@vger.kernel.org, Jeff King , "brian m . carlson" , Eric Sunshine , Johannes Schindelin Subject: Re: [PATCH v2 08/10] fsck: add new "extra" checks for "mktag" References: <20201126012854.399-1-avarab@gmail.com> <20201126222257.5629-9-avarab@gmail.com> Date: Tue, 01 Dec 2020 12:33:08 -0800 In-Reply-To: <20201126222257.5629-9-avarab@gmail.com> (=?utf-8?B?IsOGdmFy?= =?utf-8?B?IEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Thu, 26 Nov 2020 23:22:55 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: 6D3EA1FA-3414-11EB-A7F8-D609E328BF65-77302942!pb-smtp21.pobox.com Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason writes: > Add optional "extra" checks to fsck, these are needed to eventually > replace the custom not-quite-fsck code in mktag.c. > > The mktag checks differ from fsck_tag() in several ways, one of those > is that fsck doesn't know how to refuse an object with custom headers, > and isn't strict about header and body newline separation. You say "there must be only one blank line between the header and the body", but viewing from the way we parse header and body, I think that such a rule actually forbids a leading blank line in the body and steps into checking whitespace errors---makes readers wonder if we should be also detecting trailing whitespaces on lines, etc. Is there actually such a check enforced in the original? Or is this a new rule that appeared out of thin air? We'd have to inspect the lines deleted from builtin/mktag.c in the next step, I gues. > By adding an "extra" category and only reporting it based on a flag in > fsck_options callers can opt-in to these "extra" messages, which > they'll then need to deal with in their own "error_func". Makes sense.