From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id CEB571F626 for ; Fri, 17 Feb 2023 22:12:16 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=shaw.ca header.i=@shaw.ca header.a=rsa-sha256 header.s=s20180605 header.b=PGJNazui; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229551AbjBQWMO (ORCPT ); Fri, 17 Feb 2023 17:12:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229580AbjBQWMN (ORCPT ); Fri, 17 Feb 2023 17:12:13 -0500 Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F08A363BF0 for ; Fri, 17 Feb 2023 14:12:11 -0800 (PST) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id T5FApQbXNuZMST8xfpeUlb; Fri, 17 Feb 2023 22:12:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shaw.ca; s=s20180605; t=1676671931; bh=NlN9GF6kGLIU4UDu6wwWQTpWNQ7Pgu9/edlc8GRMnDU=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To; b=PGJNazuiJdhTD+QZzi3/XOH+YvvVOJSkBioGadNjatBrsZEn0h8LuybHTBNfeJ8zx u5z2LdKuUaqQtVvCID0amqAtlXPl6knef++823QH5GPLnbTQxQRsBNR5bHyugrEBpf /tjpAVPzCtn+NlRz2JOWiZLv1piqOQZ9RDfoMC7+0Z/P4cxhq5BMQVkhbvyunZa6rS aPBEVPtQQomw51HD2dzf6y0AGiZmx+TrqeHV783NNl3W/lCBgo3mW/dWLcfIpxy+Qw kYPM377c9P4RLJxIyX//QhCfr6++HTLMXG9uEwIqkZ+5+yNA42GZCpjj52S5Z77Gfq T6Q1LHsKofwAA== Received: from [10.0.0.5] ([184.64.102.149]) by cmsmtp with ESMTP id T8xepw6aN3fOST8xepj52V; Fri, 17 Feb 2023 22:12:11 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=63effbbb a=DxHlV3/gbUaP7LOF0QAmaA==:117 a=DxHlV3/gbUaP7LOF0QAmaA==:17 a=IkcTkHD0fZMA:10 a=_Dj-zB-qAAAA:8 a=VwQbUJbxAAAA:8 a=q5I91NIi_Pmg4zTliJIA:9 a=QEXdDO2ut3YA:10 a=rQFNUccIKK0A:10 a=AjGcO6oz07-iQ99wixmX:22 Message-ID: Date: Fri, 17 Feb 2023 15:12:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Reply-To: Brian.Inglis@Shaw.ca Subject: Re: manual option --inline --no-attach override required for format.attach Content-Language: en-CA To: git@vger.kernel.org Cc: Junio C Hamano References: <20230215215112.62559-1-Brian.Inglis@Shaw.ca> From: Brian Inglis Organization: Inglis In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfAmBuqrxzXlfLCZFFKKUkqmidjc2gKIdR9r3eCmfjP0Gg0OdqeX6EuG1aw+29WnBIWdBpoCSdzdiZjcB3xS3fLyyptndy3V0MAgQVgsW2uzOLqcdXLSS pDi9tFgUtpk9clHi8LTGyn0isBgAs6undY38fCJuv2RK9SApNPOzoHNgXX5q5fTMYLxdhpCZ5MeU009Xgr+VqTXvnvxW+ZPSBE4= Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 2023-02-15 15:21, Junio C Hamano wrote: > Brian Inglis writes: > >> What did you do before the bug happened? (Steps to reproduce your issue) >> git format-patch --inline ... --to=linux-man@vger.kernel.org > > This is documented to use multipart/mixed attachement with > "Content-Disposition: inline". > >> git format-patch --no-attach ... --to=linux-man@vger.kernel.org > > This should be the default, text/plain patch contained inline in the > message. > >> git send-email ... --to=linux-man@vger.kernel.org > > It is unclera what ... hides on this command line, but if you sent > output from both of the above two format-patch invocations, then the > output from the first invocation of format-patch with --inline would > be MIME multipart messages, so it is understandable if the recipient > sees such messages. Thanks Junio, I think I was being confused by a project maintainer insisting on --inline when what he really wanted was --no-attach to get inline patches for his process, no other project previously caring that /etc/gitconfig had format.attach, and my not even being aware that was set until I checked! I also found my ISP had added outgoing milter rate limiting, rejecting everything after the 5th patch email in a series, adding to our situation! But the point stands that there is no way to switch attach off in local or repo config if it is on in a more global config, other than remembering to manually specify --no-attach on every git format-patch. Suggest allowing attach=no|off|0. This would benefit those contributing from orgs tightly controlled environments where they may be unable to change global configs. There should also be a config item if project maintainers want to see --inline attachments, working in the same manner as attach, or as an argument of attach? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry