manual option --inline --no-attach override required for format.attach

What did you do before the bug happened? (Steps to reproduce your issue) git format-patch --inline ... --to=linux-man@vger.kernel.org git format-patch --no-attach ... --to=linux-man@vger.kernel.org git send-email ... --to=linux-man@vger.kernel.org

What did you expect to happen? (Expected behavior) linux-man maintainer would get patches inline not in attachments as expected

What happened instead? (Actual behavior) linux-man maintainer got patches in MIME attachments which he could not use

What's different between what you expected and what actually happened? using format-patch either --inline or --no-attach would send patches inline need to remember to specify format-patch --inline --no-attach for every patch there is no way to set config format.inline format.attach=no

Anything else you want to add: initially found format.attach set in /etc/gitconfig and no way to override would be great if linux-man maintainer could set repo config format.inline format.attach=no

[System Info] git version: git version 2.39.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: CYGWIN_NT-10.0-19044 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 compiler info: gnuc: 11.3 libc info: newlib 4.3.0 $SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks]

Brian Inglis <Brian.Inglis@Shaw.ca> writes:

This is documented to use multipart/mixed attachement with "Content-Disposition: inline".

This should be the default, text/plain patch contained inline in the message.

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.

On 2023-02-15 15:21, Junio C Hamano wrote:

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?

On 2023-02-15 at 21:51:13, Brian Inglis wrote:

I think Junio has responded to the rest of this and is more familiar with it than I am, but we don't allow repository configuration to be shipped in the repo. That's because in general configuration can contain programs or shell commands and thus execute arbitrary code, so doing so would be a security problem.

Experiences with Vim modelines have shown that embedding configuration, even when highly restricted, can be the cause of lots of security vulnerabilities, and we've seen this with config used by submodules in the past. For that and many other reasons, including the fact that users may not care what upstream's preferred settings are, it's extremely unlikely that we'll add any automatic way to ship configuration in the repository.