From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id D953C20988 for ; Tue, 18 Oct 2016 16:36:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754868AbcJRQg2 (ORCPT ); Tue, 18 Oct 2016 12:36:28 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:61116 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754585AbcJRQg0 (ORCPT ); Tue, 18 Oct 2016 12:36:26 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 4689748174; Tue, 18 Oct 2016 12:36:25 -0400 (EDT) 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; s=sasl; bh=PCtjY7oXVZ5iJ0KGhlCQGB0LkZk=; b=AsXQz1 B4l/6PrN+Ky9amP3hJEuxfdSeG0n84Gucn2pPAQOqUpZNRo+WPhdoMBuQDBNGgdr LAPJUFUNnQy/8Jlgm1kPkHamJZL1z0Pu8Grjno43swqvevold5QS6olNmeuhOUvn zx4RuMxYoTtodQGeq4jMYqQ+IrNshmJL+B19M= 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; q=dns; s=sasl; b=fV+VXt/Lp90h7UYSZ4TYS+1d4VOmbXlx sEVL0vCkRQsdxL0DyDh1vv71UXwuetVdh3/3uIl5eWzGM+I0xK3jD/m7kkHF5EVK 0Ik/e/I6S3syWnIikCBi3l9N4MdPeBy9sFtlP85Ggl1qV258xLYZ/kcAeq2+O7aY T/vzXpe9Am0= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3DF2648173; Tue, 18 Oct 2016 12:36:25 -0400 (EDT) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id AF61D48172; Tue, 18 Oct 2016 12:36:24 -0400 (EDT) From: Junio C Hamano To: Jonathan Tan Cc: Stefan Beller , "git\@vger.kernel.org" , Jakub =?utf-8?Q?Nar=C4=99bski?= Subject: Re: [PATCH v3 5/6] trailer: allow non-trailers in trailer block References: <1b3fe84e4b6126884a801e721d0a93c41fcb4184.1476466609.git.jonathantanmy@google.com> Date: Tue, 18 Oct 2016 09:36:22 -0700 In-Reply-To: (Jonathan Tan's message of "Mon, 17 Oct 2016 19:02:46 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 0272C2E0-9551-11E6-A8AC-987C12518317-77302942!pb-smtp1.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Jonathan Tan writes: >> * rs/c-auto-resets-attributes: >> pretty: avoid adding reset for %C(auto) if output is empty >> >> And neither of the two colon containing line remotely resembles how >> a typical RFC-822 header is formatted. So that may serve as a hint >> to how we can tighten it without introducing false negative. > > The only "offending" character is the space (according to RFC 822), > but that sounds like a good rule to have. I suspect that we should be willing to deviate from the letter of RFC to reject misidentification. I saw things like Thanks to: Jonathan Tan Signed-off-by: A U Thor in the wild (notice the SP between Thanks and to), for example. Rejecting leading whitespace as a line that does *not* start the header (hence its colon does not count) may be a good compromise. > I think that "Signed-off-by:" is not guaranteed to be > present. But do we really care about that case where there is no S-o-b:? I personally do not think so. > Defining a trailer line as "a line starting with a token, > then optional whitespace, then separator", maybe the following rule: > - at least one trailer line generated by Git ("(cherry picked by" or > "Signed-off-by") or configured in the "trailer" section in gitconfig > OR > - at least 3/4 logical trailer lines (I'm wondering if this should be > 100% trailer lines) I'd strongly suggest turning that OR to AND. We will not safely be able to write a commit log message that describes how S-o-b lines are handled in its last paragraph otherwise. I do not care too deeply about 3/4, but I meant to allow 75% cruft but no more than that, and the fact that the threashold is set at way more than 50% is important. IOW, if you have Ordinary log message here... S-o-b: A U Thor [a short description that is typically a single liner in the real world use pattern we saw in the world, but could overflow to become multi line cruft] S-o-b: R E Layer "last paragraph" is 5 lines long, among which 60% are cruft that is below the 75% threshold, and "am -s" can still add the S-o-b of the committer at the end of that existing last paragraph. Making it too strict would raise the false negative ratio.