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: AS31976 209.132.180.0/23 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, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id E413D1F5AD for ; Tue, 7 Apr 2020 20:31:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726386AbgDGUbM (ORCPT ); Tue, 7 Apr 2020 16:31:12 -0400 Received: from cloud.peff.net ([104.130.231.41]:36370 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726277AbgDGUbM (ORCPT ); Tue, 7 Apr 2020 16:31:12 -0400 Received: (qmail 4045 invoked by uid 109); 7 Apr 2020 20:31:12 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with SMTP; Tue, 07 Apr 2020 20:31:12 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 1343 invoked by uid 111); 7 Apr 2020 20:41:36 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Tue, 07 Apr 2020 16:41:36 -0400 Authentication-Results: peff.net; auth=none Date: Tue, 7 Apr 2020 16:31:11 -0400 From: Jeff King To: Junio C Hamano Cc: Emma Brooks , git@vger.kernel.org, Denton Liu , Eric Sunshine Subject: Re: [PATCH] format-patch: teach --no-encode-headers Message-ID: <20200407203111.GA1936475@coredump.intra.peff.net> References: <20200405231109.8249-1-me@pluvano.com> <20200407034622.GA42812@pluvano.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, Apr 07, 2020 at 12:37:31PM -0700, Junio C Hamano wrote: > Emma Brooks writes: > > > It's also too vague and it's not entirely clear from the option itself > > what sort of encoding it refers to. I will change it to > > --[no-]q-encode-headers and format.qEncodeHeaders in v2 unless there are > > other suggestions. > > I actually did not mean to push you into that direction. We can, > and do want to, keep the most generic "--[no-]encode-headers" if we > do not anticipate us wanting to special case the Q encoding. A > sample question to ask is "would it make sense to disable q-encoding > but still perform other parts of 'encode headers'?" I haven't > thought deeply about such questions, but as a proposer of this > topic, you would certainly have, and I was hoping that you'd say > things like "Q-encoding is the only thing that we do to munge > headers, so there aren't any 'other parts of encoding headers' we > need to worry about", "there are things like X, Y and Z that we do > to the headers when we enable Q-encoding, but they all are what we > do not want when we do not want the Q-encoding", which would be a > very good sign that assures us that "--[no-]encode-headers" is a > good name. I thought we might b-encode some headers, but couldn't find any code to do so (after about 5 minutes of looking). However, this new option isn't just for format-patch. It is available for all revision walkers (as it should be; I can say "log --format=email" and I might want to use it there). And there "headers" is less clear that we are talking about email headers, and not other object headers (e.g., that you might see with --format=raw). Saying "--no-rfc2047-encoding" would be more descriptive to _me_, but I wonder if people not so familiar with the standards would find it a bit obscure. Another option is to invert it to "--8bit-email-headers" or something. -Peff