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-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 258A11F5AE for ; Thu, 29 Apr 2021 19:02:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234056AbhD2TD2 (ORCPT ); Thu, 29 Apr 2021 15:03:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233830AbhD2TD1 (ORCPT ); Thu, 29 Apr 2021 15:03:27 -0400 Received: from mav.lukeshu.com (mav.lukeshu.com [IPv6:2001:19f0:5c00:8069:5400:ff:fe26:6a86]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F605C06138C for ; Thu, 29 Apr 2021 12:02:40 -0700 (PDT) Received: from lukeshu-dw-thinkpad (unknown [IPv6:2601:281:8200:26:527b:9dff:fe2b:180a]) by mav.lukeshu.com (Postfix) with ESMTPSA id AC9DC80590; Thu, 29 Apr 2021 15:02:31 -0400 (EDT) Date: Thu, 29 Apr 2021 13:02:28 -0600 Message-ID: <87pmycq5h7.wl-lukeshu@lukeshu.com> From: Luke Shumaker To: Junio C Hamano Cc: Luke Shumaker , git@vger.kernel.org, Elijah Newren , Jeff King , Johannes Schindelin , =?UTF-8?B?Tmd1eeG7hW4g?= =?ISO-8859-1?Q?Th?= =?ISO-8859-1?Q?=E1i_?= =?UTF-8?B?Tmfhu41j?= Duy , Taylor Blau , "brian m . carlson" , Eric Sunshine , Luke Shumaker Subject: Re: [PATCH v3 2/3] fast-export: rename --signed-tags='warn' to 'warn-verbatim' In-Reply-To: References: <20210422002749.2413359-1-lukeshu@lukeshu.com> <20210423164118.693197-1-lukeshu@lukeshu.com> <20210423164118.693197-3-lukeshu@lukeshu.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, 27 Apr 2021 21:29:12 -0600, Junio C Hamano wrote: > Luke Shumaker writes: > > > ---signed-tags=(verbatim|warn|warn-strip|strip|abort):: > > +--signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort):: > > Specify how to handle signed tags. Since any transformation > > after the export can change the tag names (which can also happen > > when excluding revisions) the signatures will not match. > > @@ -36,8 +36,10 @@ When asking to 'abort' (which is the default), this program will die > > when encountering a signed tag. With 'strip', the tags will silently > > be made unsigned, with 'warn-strip' they will be made unsigned but a > > warning will be displayed, with 'verbatim', they will be silently > > -exported and with 'warn', they will be exported, but you will see a > > -warning. > > +exported and with 'warn-verbatim', they will be exported, but you will > > +see a warning. > > ++ > > +`warn` is a deprecated synonym of `warn-verbatim`. > > Two minor points > > - Is it obvious to everybody what is the implication of using > "verbatim" (which in turn would bring the readers to realize why > it often deserves a warning)? If not, would it make sense to > explain why "verbatim" may (may not) be a good idea in different > situations? I had assumed that the above paragraph | Specify how to handle signed tags. Since any transformation | after the export can change the tag names (which can also happen | when excluding revisions) the signatures will not match. was adaquate for that purpose, but we can maybe do better? > - I am not sure a deprecated synonym deserves a separate paragraph. Fair enough. My thinking was to keep the deprecation separate from the main "happy path" text. How about: | Specify how to handle signed tags. Since any transformation after the | export (or during the export, such as excluding revisions) can change | the hashes being signed, the signatures may not match. | | When asking to 'abort' (which is the default), this program will die | when encountering a signed tag. With 'strip', the tags will silently | be made unsigned, with 'warn-strip' they will be made unsigned but a | warning will be displayed, with 'verbatim', they will be silently | exported and with 'warn-verbatim' (or 'warn', a deprecated synonym), | they will be exported, but you will see a warning. 'verbatim' should | not be used unless you know that no transformations affecting tags | will be performed, or unless you do not care that the resulting tag | will have an invalid signature. ? > > diff --git a/builtin/fast-export.c b/builtin/fast-export.c > > index 85a76e0ef8..d121dd2ee6 100644 > > --- a/builtin/fast-export.c > > +++ b/builtin/fast-export.c > > @@ -55,7 +55,7 @@ static int parse_opt_signed_tag_mode(const struct option *opt, > > signed_tag_mode = SIGNED_TAG_ABORT; > > else if (!strcmp(arg, "verbatim") || !strcmp(arg, "ignore")) > > signed_tag_mode = VERBATIM; > > - else if (!strcmp(arg, "warn")) > > + else if (!strcmp(arg, "warn-verbatim") || !strcmp(arg, "warn")) > > signed_tag_mode = WARN; > > else if (!strcmp(arg, "warn-strip")) > > signed_tag_mode = WARN_STRIP; > > It would be preferrable to do s/WARN/WARN_VERBATIM/ at this step, as > the plan is to deprecate "warn", even if you are going to redo the > enums in later steps. May want to consider doing so as a clean-up > iff this topic need rerolling for other reasons. Ack. > > diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh > > index 409b48e244..892737439b 100755 > > --- a/t/t9350-fast-export.sh > > +++ b/t/t9350-fast-export.sh > > @@ -253,6 +253,24 @@ test_expect_success 'signed-tags=verbatim' ' > > > > ' > > > > +test_expect_success 'signed-tags=warn-verbatim' ' > > + > > + git fast-export --signed-tags=warn-verbatim sign-your-name >output 2>err && > > + grep PGP output && > > + test -s err > > I didn't look at the surrounding existing tests, but in general > "test -s err" is not a good ingredient in any test. The feature you > happen to care about today may not stay to be be the only thing that > writes to the standard error stream. Yeah, that line made me nervous, but I figured if it was good enough for the existing 'warn-strip' test, then it was good enough for 'warn-verbatim' too. -- Happy hacking, ~ Luke Shumaker