{"thread":{"id":"60484","subject":"git-send-email: Send with mutt(1)","startedAt":"2023-11-07T11:11:29Z","lastAt":"2023-11-10T23:31:58Z","messageCount":17,"participants":["Alejandro Colomar","Jeff King","Konstantin Ryabitsev","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"484524","messageId":"ZUocFhmPHstwKCkZ@devuan","threadId":"60484","inReplyTo":null,"subject":"git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-07T11:14:21Z","receivedAt":"2023-11-07T11:11:29Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi!\n\nI'm trying to use mutt(1) with git-send-email(1). Is that possible?\nI tried --sendmail-cmd=mutt, but am getting strange errors.\nThe reason I want to send with mutt(1) is because it can encrypt and\nsign mail (with some tweaks), which git-send-mail(1) doesn't.\n\nThanks,\nAlex\n-- \n\n"},{"id":"484535","messageId":"20231107174803.GA507007@coredump.intra.peff.net","threadId":"60484","inReplyTo":"ZUocFhmPHstwKCkZ@devuan","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-11-07T17:48:03Z","receivedAt":"2023-11-07T17:48:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 07, 2023 at 12:14:21PM +0100, Alejandro Colomar wrote:\n\n> I'm trying to use mutt(1) with git-send-email(1). Is that possible?\n> I tried --sendmail-cmd=mutt, but am getting strange errors.\n> The reason I want to send with mutt(1) is because it can encrypt and\n> sign mail (with some tweaks), which git-send-mail(1) doesn't.\n\nI think there's a lot of overlap between what git-send-email does and\nwhat mutt does, to the point that you probably don't need to use\nsend-email at all.\n\nI assume what you want out of send-email here is the actual generation\nof patch emails. But under the hood that is all done by git-format-patch\nanyway. So for example if you do:\n\n git format-patch --stdout origin..HEAD >patches\n mutt -f patches\n\nAnd then you can use mutt's \"resend-message\" function to send each one.\nI use config like this:\n\n macro index,pager b \":set edit_headers=yes:set edit_headers=no\"\n\nIf you're sending a long series, it's helpful to pre-populate various\nheaders in the format-patch command with \"--to\", etc. I usually do so by\nsending the cover letter directly via mutt, and then using some perl\nhackery to convert those headers into format-patch args. The script I\nuse is below (it will also, when run without a terminal, generate the\npatch summary for the cover letter; I use it with \"r!my-script\" while\nwriting the cover letter in vim).\n\n(This script is what I use every day, so it should be fairly robust. But\nit is also over 15 years old, so I don't promise there isn't a simpler\nway to do some of what it does ;) ).\n\n-- >8 --\n#!/bin/sh\nupstream_branch() {\n current=`git symbolic-ref HEAD`\n upstream=`git for-each-ref --format='%(upstream)' \"$current\"`\n if test -n \"$upstream\"; then\n echo $upstream\n else\n echo origin\n fi\n}\n\nget_reply_headers() {\n perl -ne '\n if (defined $opt) {\n if (/^\\s+(.*)/) {\n $val .= \" $1\";\n next;\n }\n print \"--$opt=\", quotemeta($val), \" \";\n $opt = $val = undef;\n }\n if (/^(cc|to):\\s*(.*)/i) {\n $opt = lc($1);\n $val = $2;\n }\n elsif (/^message-id:\\s*(.*)/i) {\n $opt = \"in-reply-to\";\n $val = $1;\n }\n elsif (/^subject:\\s*\\[PATCH v(\\d+)/i) {\n print \"-v$1 \";\n }\n elsif (/^$/) {\n last;\n }\n '\n}\n\nformat_patch() {\n git format-patch -s --stdout --from \"$@\"\n}\n\nhas_nonoption=\nfor i in \"$@\"; do\n case \"$i\" in\n -[0-9]*) has_nonoption=yes ;;\n -*) ;;\n *) has_nonoption=yes\n esac\ndone\n\n: ${REPLY:=$HOME/patch}\ntest -e \"$REPLY\" && eval \"set -- `get_reply_headers <\\\"$REPLY\\\"` \\\"\\$@\\\"\"\ntest \"$has_nonoption\" = \"yes\" || set -- \"$@\" `upstream_branch`\n\nif test -t 1; then\n format_patch \"$@\" >.mbox\n mutt -e 'set sort=mailbox-order' -f .mbox\n rm -f .mbox\nelse\n format_patch \"$@\" |\n perl -lne '\n if (/^Subject: (.*)/) {\n $subject = $1;\n }\n elsif ($subject && /^\\s+(.*)/) {\n $subject .= \" $1\";\n }\n elsif ($subject) {\n print $subject;\n $subject = undef;\n }\n ' |\n sed -e 's/\\[PATCH /[/' \\\n -e 's/]/]:/' \\\n -e 's/^/ /'\n echo\n format_patch --cover-letter \"$@\" |\n sed -ne '/|/,/^$/p; /^-- /q'\nfi\n"},{"id":"484541","messageId":"ZUqDwnmu9d1dD1tb@devuan","threadId":"60484","inReplyTo":"20231107174803.GA507007@coredump.intra.peff.net","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-07T18:36:44Z","receivedAt":"2023-11-07T18:33:48Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Jeff,\n\nOn Tue, Nov 07, 2023 at 12:48:03PM -0500, Jeff King wrote:\n> I think there's a lot of overlap between what git-send-email does and\n> what mutt does, to the point that you probably don't need to use\n> send-email at all.\n> \n> I assume what you want out of send-email here is the actual generation\n> of patch emails. But under the hood that is all done by git-format-patch\n> anyway. So for example if you do:\n\nYeah, most of it is done by format-patch. There are few things I\nactually need from send-email. One of them is generating the Cc from\nthe sign-offs and other tags found in the patch.\n\nI had been thinking these days that it would be useful to have\nformat-patch generate those. How about adding a --signed-off-by-cc to\nformat-patch?\n\n> \n> git format-patch --stdout origin..HEAD >patches\n> mutt -f patches\n> \n> And then you can use mutt's \"resend-message\" function to send each one.\n> I use config like this:\n> \n> macro index,pager b \":set edit_headers=yes:set edit_headers=no\"\n> \n> If you're sending a long series, it's helpful to pre-populate various\n> headers in the format-patch command with \"--to\", etc. I usually do so by\n> sending the cover letter directly via mutt, and then using some perl\n> hackery to convert those headers into format-patch args. The script I\n\nIndeed, that hackery is what send-email already does, so how about\nmoving those features a bit upstream so that format-patch can do them\ntoo?\n\nAlthough then, maybe it's simpler to teach send-email to learn to use\nmutt(1) under the hood for the actual send.\n\n> use is below (it will also, when run without a terminal, generate the\n> patch summary for the cover letter; I use it with \"r!my-script\" while\n> writing the cover letter in vim).\n> \n> (This script is what I use every day, so it should be fairly robust. But\n> it is also over 15 years old, so I don't promise there isn't a simpler\n> way to do some of what it does ;) ).\n> \n> -- >8 --\n> #!/bin/sh\n> upstream_branch() {\n> current=`git symbolic-ref HEAD`\n> upstream=`git for-each-ref --format='%(upstream)' \"$current\"`\n> if test -n \"$upstream\"; then\n> echo $upstream\n> else\n> echo origin\n> fi\n> }\n> \n> get_reply_headers() {\n> perl -ne '\n> if (defined $opt) {\n> if (/^\\s+(.*)/) {\n> $val .= \" $1\";\n> next;\n> }\n> print \"--$opt=\", quotemeta($val), \" \";\n> $opt = $val = undef;\n> }\n> if (/^(cc|to):\\s*(.*)/i) {\n> $opt = lc($1);\n> $val = $2;\n> }\n> elsif (/^message-id:\\s*(.*)/i) {\n> $opt = \"in-reply-to\";\n> $val = $1;\n> }\n> elsif (/^subject:\\s*\\[PATCH v(\\d+)/i) {\n> print \"-v$1 \";\n> }\n> elsif (/^$/) {\n> last;\n> }\n> '\n> }\n> \n> format_patch() {\n> git format-patch -s --stdout --from \"$@\"\n> }\n> \n> has_nonoption=\n> for i in \"$@\"; do\n> case \"$i\" in\n> -[0-9]*) has_nonoption=yes ;;\n> -*) ;;\n> *) has_nonoption=yes\n> esac\n> done\n> \n> : ${REPLY:=$HOME/patch}\n> test -e \"$REPLY\" && eval \"set -- `get_reply_headers <\\\"$REPLY\\\"` \\\"\\$@\\\"\"\n> test \"$has_nonoption\" = \"yes\" || set -- \"$@\" `upstream_branch`\n> \n> if test -t 1; then\n> format_patch \"$@\" >.mbox\n> mutt -e 'set sort=mailbox-order' -f .mbox\n> rm -f .mbox\n> else\n> format_patch \"$@\" |\n> perl -lne '\n> if (/^Subject: (.*)/) {\n> $subject = $1;\n> }\n> elsif ($subject && /^\\s+(.*)/) {\n> $subject .= \" $1\";\n> }\n> elsif ($subject) {\n> print $subject;\n> $subject = undef;\n> }\n> ' |\n> sed -e 's/\\[PATCH /[/' \\\n> -e 's/]/]:/' \\\n> -e 's/^/ /'\n> echo\n> format_patch --cover-letter \"$@\" |\n> sed -ne '/|/,/^$/p; /^-- /q'\n> fi\n\nThanks! I'll try it. Although I don't know perl, so I hope I don't\nneed to tweak it much. :)\n\nCheers,\nAlex\n\n-- \n\n"},{"id":"484546","messageId":"20231107201655.GA507701@coredump.intra.peff.net","threadId":"60484","inReplyTo":"ZUqDwnmu9d1dD1tb@devuan","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-11-07T20:16:55Z","receivedAt":"2023-11-07T20:16:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 07, 2023 at 07:36:44PM +0100, Alejandro Colomar wrote:\n\n> > I assume what you want out of send-email here is the actual generation\n> > of patch emails. But under the hood that is all done by git-format-patch\n> > anyway. So for example if you do:\n> \n> Yeah, most of it is done by format-patch. There are few things I\n> actually need from send-email. One of them is generating the Cc from\n> the sign-offs and other tags found in the patch.\n> \n> I had been thinking these days that it would be useful to have\n> format-patch generate those. How about adding a --signed-off-by-cc to\n> format-patch?\n\nThat seems like a reasonable feature. Probably it should be\n--cc-from-trailer=signed-off-by, and then you could do the same with\nother trailers.\n\nIt feels like you could _almost_ do it with the existing\n--format='%(trailers)' functionality, but there's no way to say \"do the\nregular --format=email output, but also stick this extra format in the\nheaders section\". Plus there are probably some niceties you'd get from\nGit knowing that you're adding headers (like de-duping addresses).\n\nThat feature might end up somewhat hairy, though, as then you get into\nquestions of parsing address lists, etc. We do all that now in perl with\nsend-email, where we can lean on some parsing libraries. So I dunno.\n\n> > If you're sending a long series, it's helpful to pre-populate various\n> > headers in the format-patch command with \"--to\", etc. I usually do so by\n> > sending the cover letter directly via mutt, and then using some perl\n> > hackery to convert those headers into format-patch args. The script I\n> \n> Indeed, that hackery is what send-email already does, so how about\n> moving those features a bit upstream so that format-patch can do them\n> too?\n\nYeah, if they existed in format-patch I might be able to reuse them. I\nam hesitant, though, just because handling all the corner cases on\nparsing is going to be a bit of new C code.\n\n> Although then, maybe it's simpler to teach send-email to learn to use\n> mutt(1) under the hood for the actual send.\n\nI think you will find some corner cases in trying to make mutt act just\nlike an mta accepting delivery. Two I can think of:\n\n 1. It will take a body on stdin, but not a whole message. We can hack\n around that with some postponed-folder magic, though.\n\n 2. Bcc headers are stripped before sendmail sees the message (but\n those addresses appear on the command-line). Converting that back\n to bcc so that mutt can then re-strip them would be annoying but\n possible. If you don't use bcc, it probably makes sense to just\n punt on this.\n\nSo maybe a script like this:\n\n-- >8 --\n#!/bin/sh\n\n# ignore arguments; mutt will parse them itself\n# from to/cc headers. Note that we'll miss bcc this\n# way, but handling that would probably be kind of\n# tricky; we'd need to re-add those recipients as actual\n# bcc headers so that mutt knows how to handle them.\n\n# spool the message to a fake mbox; we need to add\n# a \"From\" line to make it look legit\ntrap 'rm -f to-send' 0 &&\n{\n echo \"From whatever Mon Sep 17 00:00:00 2001\" &&\n cat\n} >to-send &&\n\n# and then have mutt \"resume\" it. We have to redirect\n# stdin back from the terminal, since ours is a pipe\n# with the message contents.\nmutt -p \\\n -e 'set postponed=to-send' \\\n -e 'set edit_headers=yes' \\\n > I had been thinking these days that it would be useful to have\n> > format-patch generate those. How about adding a --signed-off-by-cc to\n> > format-patch?\n> \n> That seems like a reasonable feature. Probably it should be\n> --cc-from-trailer=signed-off-by, and then you could do the same with\n> other trailers.\n\nThat would work for me. I only suggested the other one because it's\naleady in send-email in that form. But yeah, it might be useful to have\nfiner control. In my case, something that CCs every mail in the trailer\nwould work (Reviewed-by, Suggested-by, ... I want them all, always).\n\n> \n> It feels like you could _almost_ do it with the existing\n> --format='%(trailers)' functionality, but there's no way to say \"do the\n> regular --format=email output, but also stick this extra format in the\n> headers section\". Plus there are probably some niceties you'd get from\n> Git knowing that you're adding headers (like de-duping addresses).\n> \n> That feature might end up somewhat hairy, though, as then you get into\n> questions of parsing address lists, etc. We do all that now in perl with\n> send-email, where we can lean on some parsing libraries. So I dunno.\n\nHmmm.\n\n> \n> > > If you're sending a long series, it's helpful to pre-populate various\n> > > headers in the format-patch command with \"--to\", etc. I usually do so by\n> > > sending the cover letter directly via mutt, and then using some perl\n> > > hackery to convert those headers into format-patch args. The script I\n> > \n> > Indeed, that hackery is what send-email already does, so how about\n> > moving those features a bit upstream so that format-patch can do them\n> > too?\n> \n> Yeah, if they existed in format-patch I might be able to reuse them. I\n> am hesitant, though, just because handling all the corner cases on\n> parsing is going to be a bit of new C code.\n> \n> > Although then, maybe it's simpler to teach send-email to learn to use\n> > mutt(1) under the hood for the actual send.\n> \n> I think you will find some corner cases in trying to make mutt act just\n> like an mta accepting delivery. Two I can think of:\n> \n> 1. It will take a body on stdin, but not a whole message. We can hack\n> around that with some postponed-folder magic, though.\n> \n> 2. Bcc headers are stripped before sendmail sees the message (but\n> those addresses appear on the command-line). Converting that back\n> to bcc so that mutt can then re-strip them would be annoying but\n> possible. If you don't use bcc, it probably makes sense to just\n> punt on this.\n\nMeh, I can live with no Bcc feature; I never used it before. :)\n\n> \n> So maybe a script like this:\n> \n> -- >8 --\n> #!/bin/sh\n> \n> # ignore arguments; mutt will parse them itself\n> # from to/cc headers. Note that we'll miss bcc this\n> # way, but handling that would probably be kind of\n> # tricky; we'd need to re-add those recipients as actual\n> # bcc headers so that mutt knows how to handle them.\n> \n> # spool the message to a fake mbox; we need to add\n> # a \"From\" line to make it look legit\n> trap 'rm -f to-send' 0 &&\n> {\n> echo \"From whatever Mon Sep 17 00:00:00 2001\" &&\n> cat\n> } >to-send &&\n\nWould a named pipe work? Or maybe we could use $(mktemp)?\n\n> \n> # and then have mutt \"resume\" it. We have to redirect\n> # stdin back from the terminal, since ours is a pipe\n> # with the message contents.\n> mutt -p \\\n> -e 'set postponed=to-send' \\\n> -e 'set edit_headers=yes' \\\n> -- 8< --\n\nHuh, this is magic sauce! Works perfect for what I need. This would\nneed to be packaged to the masses. :-)\n\nI found a minor problem: If I ctrl+C within mutt(1), I expect it to\ncancel the last action, but this script intercepts the signal and exits.\nWe would probably need to ignore SIGINT from mutt-as-mta.\n\nOther than that, this fulfills all of my needs.\n\nWould you mind adding this as part of git? Or should we suggest the\nmutt project adding this script?\n\n\nThanks a lot!\n\nCheers,\nAlex\n\n> \n> and then in your git config:\n> \n> [sendemail]\n> sendmailcmd = /path/to/mutt-as-mta.sh\n> \n> There are mutt-specific bits there that I don't think send-email should\n> have to know about. Perhaps there are generic options that send-email\n> could learn, but it really feels like you'd do better teaching mutt to\n> be more ready to handle this (like taking a whole message on stdin,\n> headers and all, rather than just a body).\n> \n> -Peff\n\n-- \n\n"},{"id":"484595","messageId":"20231108212702.GA1586965@coredump.intra.peff.net","threadId":"60484","inReplyTo":"ZUv3gjjmuqvCaJEd@debian","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-11-08T21:27:02Z","receivedAt":"2023-11-08T21:27:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 08, 2023 at 10:02:52PM +0100, Alejandro Colomar wrote:\n\n> > That seems like a reasonable feature. Probably it should be\n> > --cc-from-trailer=signed-off-by, and then you could do the same with\n> > other trailers.\n> \n> That would work for me. I only suggested the other one because it's\n> aleady in send-email in that form. But yeah, it might be useful to have\n> finer control. In my case, something that CCs every mail in the trailer\n> would work (Reviewed-by, Suggested-by, ... I want them all, always).\n\nOh, I didn't realize it existed in send-email. I am showing my ignorance\nof it. ;)\n\n> > # spool the message to a fake mbox; we need to add\n> > # a \"From\" line to make it look legit\n> > trap 'rm -f to-send' 0 &&\n> > {\n> > echo \"From whatever Mon Sep 17 00:00:00 2001\" &&\n> > cat\n> > } >to-send &&\n> \n> Would a named pipe work? Or maybe we could use $(mktemp)?\n\nI suspect mutt wants it to be a real file. But yeah, mktemp would\ndefinitely work. I actually started to write it that way but switched to\na static name for simplicity in demonstrating the idea. :)\n\nOne note, though. Later we need to pass this filename to mutt config:\n\n> > mutt -p \\\n> > -e 'set postponed=to-send' \\\n\nso it's a potential worry if \"mktemp\" might use a path with spaces or\nfunny characters (e.g., from $TMPDIR). Probably not much of a problem in\npractice, though.\n\n> Huh, this is magic sauce! Works perfect for what I need. This would\n> need to be packaged to the masses. :-)\n> \n> I found a minor problem: If I ctrl+C within mutt(1), I expect it to\n> cancel the last action, but this script intercepts the signal and exits.\n> We would probably need to ignore SIGINT from mutt-as-mta.\n\nYeah, that might make sense, and can be done with trap.\n\n> Would you mind adding this as part of git? Or should we suggest the\n> mutt project adding this script?\n\nIMHO it is a little too weird and user-specific to really make sense in\neither project. It's really glue-ing together two systems. And as it's\nnot something I use myself, I don't plan it moving it further along. But\nyou are welcome to take what I wrote and do what you will with it,\nincluding submitting it to mutt.\n\n-Peff\n"},{"id":"484647","messageId":"ZUz6H3IqRc1YGPZM@debian","threadId":"60484","inReplyTo":"20231108212702.GA1586965@coredump.intra.peff.net","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-09T15:26:23Z","receivedAt":"2023-11-09T15:26:26Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Jeff,\n\nOn Wed, Nov 08, 2023 at 04:27:02PM -0500, Jeff King wrote:\n> > > # spool the message to a fake mbox; we need to add\n> > > # a \"From\" line to make it look legit\n> > > trap 'rm -f to-send' 0 &&\n> > > {\n> > > echo \"From whatever Mon Sep 17 00:00:00 2001\" &&\n> > > cat\n> > > } >to-send &&\n> > \n> > Would a named pipe work? Or maybe we could use $(mktemp)?\n> \n> I suspect mutt wants it to be a real file. But yeah, mktemp would\n> definitely work. I actually started to write it that way but switched to\n> a static name for simplicity in demonstrating the idea. :)\n> \n> One note, though. Later we need to pass this filename to mutt config:\n> \n> > > mutt -p \\\n> > > -e 'set postponed=to-send' \\\n> \n> so it's a potential worry if \"mktemp\" might use a path with spaces or\n> funny characters (e.g., from $TMPDIR). Probably not much of a problem in\n> practice, though.\n> \n> > Huh, this is magic sauce! Works perfect for what I need. This would\n> > need to be packaged to the masses. :-)\n> > \n> > I found a minor problem: If I ctrl+C within mutt(1), I expect it to\n> > cancel the last action, but this script intercepts the signal and exits.\n> > We would probably need to ignore SIGINT from mutt-as-mta.\n> \n> Yeah, that might make sense, and can be done with trap.\n\nI've tried something even simpler:\n\n---8<---\n#!/bin/sh\n\nmutt -H -;\n--->8---\n\nI used it for sending a couple of patches to linux-man@, and it seems to\nwork. I don't have much experience with mutt, so maybe I'm missing some\ncorner cases. Do you expect it to not work for some case? Otherwise,\nwe might have a winner. :)\n\n> \n> > Would you mind adding this as part of git? Or should we suggest the\n> > mutt project adding this script?\n> \n> IMHO it is a little too weird and user-specific to really make sense in\n> either project. It's really glue-ing together two systems. And as it's\n> not something I use myself, I don't plan it moving it further along. But\n> you are welcome to take what I wrote and do what you will with it,\n> including submitting it to mutt.\n\nI'll start by creating a git repository in my own server, and will write\nsomething about it to let the public know about it. I'll also start\nrequiring contributors to linux-man@ to sign their patches, and\nrecommend them using this if they use mutt(1).\n\nCheers,\nAlex\n\n-- \n\n"},{"id":"484648","messageId":"vooebygemslmvmi4fzxtcl474wefcvxnigqeestmruzrsj5zsu@5kkq3pveol6c","threadId":"60484","inReplyTo":"ZUz6H3IqRc1YGPZM@debian","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2023-11-09T16:08:58Z","receivedAt":"2023-11-09T16:09:00Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Nov 09, 2023 at 04:26:23PM +0100, Alejandro Colomar wrote:\n> I used it for sending a couple of patches to linux-man@, and it seems to\n> work. I don't have much experience with mutt, so maybe I'm missing some\n> corner cases. Do you expect it to not work for some case? Otherwise,\n> we might have a winner. :)\n\nSince it's a Linux project, I suggest also checking out b4, which will do the\nmail sending for you as part of the contributor-oriented features:\n\nhttps://b4.docs.kernel.org/en/latest/contributor/overview.html\n\nWe also provide a web relay for people who can't configure or use SMTP due to\ntheir company policies.\n\n> > > Would you mind adding this as part of git? Or should we suggest the\n> > > mutt project adding this script?\n> > \n> > IMHO it is a little too weird and user-specific to really make sense in\n> > either project. It's really glue-ing together two systems. And as it's\n> > not something I use myself, I don't plan it moving it further along. But\n> > you are welcome to take what I wrote and do what you will with it,\n> > including submitting it to mutt.\n> \n> I'll start by creating a git repository in my own server, and will write\n> something about it to let the public know about it. I'll also start\n> requiring contributors to linux-man@ to sign their patches, and\n> recommend them using this if they use mutt(1).\n\nB4 will also sign your patches for you. ;)\n\n-K\n"},{"id":"484649","messageId":"ZU0aAQhVj7BQwr0q@debian","threadId":"60484","inReplyTo":"vooebygemslmvmi4fzxtcl474wefcvxnigqeestmruzrsj5zsu@5kkq3pveol6c","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-09T17:42:19Z","receivedAt":"2023-11-09T17:42:28Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Konstantin,\n\nOn Thu, Nov 09, 2023 at 11:08:58AM -0500, Konstantin Ryabitsev wrote:\n> On Thu, Nov 09, 2023 at 04:26:23PM +0100, Alejandro Colomar wrote:\n> > I used it for sending a couple of patches to linux-man@, and it seems to\n> > work. I don't have much experience with mutt, so maybe I'm missing some\n> > corner cases. Do you expect it to not work for some case? Otherwise,\n> > we might have a winner. :)\n> \n> Since it's a Linux project, I suggest also checking out b4, which will do the\n> mail sending for you as part of the contributor-oriented features:\n> \n> https://b4.docs.kernel.org/en/latest/contributor/overview.html\n> \n> We also provide a web relay for people who can't configure or use SMTP due to\n> their company policies.\n> \n> > > > Would you mind adding this as part of git? Or should we suggest the\n> > > > mutt project adding this script?\n> > > \n> > > IMHO it is a little too weird and user-specific to really make sense in\n> > > either project. It's really glue-ing together two systems. And as it's\n> > > not something I use myself, I don't plan it moving it further along. But\n> > > you are welcome to take what I wrote and do what you will with it,\n> > > including submitting it to mutt.\n> > \n> > I'll start by creating a git repository in my own server, and will write\n> > something about it to let the public know about it. I'll also start\n> > requiring contributors to linux-man@ to sign their patches, and\n> > recommend them using this if they use mutt(1).\n> \n> B4 will also sign your patches for you. ;)\n\nI haven't yet tried b4(1), and considered trying it some time ago, but\nreally didn't find git-send-email(1) and mutt(1) so difficult to use\nthat b4(1) would simplify much. But still, I'll give it a chance.\nMaybe I see why afterwards.\n\nBut I have tried patatt(1) before, which is what I think b4(1) uses for\nsigning. Here are some of my concerns about patatt(4):\n\nIt doesn't sign the mail, but just the patch. There's not much\ndifference, if any, in authenticability terms, but there's a big\ndifference in usability terms:\n\nTo authenticate a given patch submitted to a mailing list, the receiver\nneeds to also have patatt(1) configured. Otherwise, it looks like a\nrandom message. MUAs normally don't show random headers (patatt(1)\nsigns by adding the signature header), so unless one is searching for\nthat header, it will be ignored. This means, if I contribute to other\nprojects, I need to tell them my patch is signed via patatt(1) in\norder for them to verify. If instead, I sign the email as usual with my\nMUA, every MUA will recognize the signature by default and show it to\nthe reader.\n\nIt also doesn't allow encrypting mail, so let's say I send some patch\nfixing a security vulnerability, I'll need a custom tool to send it. If\ninstead, I use mutt(1) to send it signed+encrypted to a mailing list\nthat provides a PGP public key, I can reuse my usual tools.\n\nAlso, and I don't know if b4(1) handles this automagically, but AFAIR,\npatatt(1) didn't: fo signing a patch, I had to configure per-directory\nwith `patatt install-hook`. I have more than a hundred git worktrees\n(think of dozens of git repositories, and half a dozen worktrees --see\ngit-worktree(1)-- per repository). If I need to configure every one of\nthose worktrees to sign all of my patches, that's going to be\ncumbersome. Also, I scrape and re-create worktrees for new branches\nall the time, so I'd need to be installing hooks for patatt(1) all the\ntime. Compare that to having mutt(1) configured once. It doesn't\nscale that well.\n\nCheers,\nAlex\n\n> \n> -K\n\n-- \n\n"},{"id":"484651","messageId":"5yn2w52iymgnobesoi2jdwpyzaf5foc4sytxfdzl4vavlox62j@7att57ya6scz","threadId":"60484","inReplyTo":"ZU0aAQhVj7BQwr0q@debian","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2023-11-09T17:59:23Z","receivedAt":"2023-11-09T17:59:24Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Nov 09, 2023 at 06:42:19PM +0100, Alejandro Colomar wrote:\n> I haven't yet tried b4(1), and considered trying it some time ago, but\n> really didn't find git-send-email(1) and mutt(1) so difficult to use\n> that b4(1) would simplify much.\n\nWell, sending is only a small part of what b4 will do for you -- the core\nbenefits are really cover letter management, automatic versioning and\nsimplified list trailer collection. It's all tailored to kernel needs, but it\nwill work for any project that depends on mailed patches.\n\n> But I have tried patatt(1) before, which is what I think b4(1) uses for\n> signing. Here are some of my concerns about patatt(4):\n> \n> It doesn't sign the mail, but just the patch.\n\nWell, no, it signs the entire thing, not just the patch, but it's true that\nit's specifically targeted at patches (hence the name).\n\n> There's not much\n> difference, if any, in authenticability terms, but there's a big\n> difference in usability terms:\n> \n> To authenticate a given patch submitted to a mailing list, the receiver\n> needs to also have patatt(1) configured. Otherwise, it looks like a\n> random message.\n\nYes, but that's a feature.\n\n> MUAs normally don't show random headers (patatt(1)\n> signs by adding the signature header), so unless one is searching for\n> that header, it will be ignored. This means, if I contribute to other\n> projects, I need to tell them my patch is signed via patatt(1) in\n> order for them to verify. If instead, I sign the email as usual with my\n> MUA, every MUA will recognize the signature by default and show it to\n> the reader.\n\nI go into this in the FAQ for patatt:\nhttps://github.com/mricon/patatt#why-not-simply-pgp-sign-all-patches\n\nBasically, developers really hated getting patches signed with PGP, either\ninline or MIME, which is why it never took off. Putting it into the header\nwhere it's not seen except by specialized tooling was a design choice.\n\n> It also doesn't allow encrypting mail, so let's say I send some patch\n> fixing a security vulnerability, I'll need a custom tool to send it. If\n> instead, I use mutt(1) to send it signed+encrypted to a mailing list\n> that provides a PGP public key, I can reuse my usual tools.\n\nRight, the goal was really *just* attestation. For encrypted patch exchange we\nhave remail (https://korg.docs.kernel.org/remail.html), which worked\nsignificantly better than any other alternative we've considered.\n\n> Also, and I don't know if b4(1) handles this automagically, but AFAIR,\n> patatt(1) didn't: fo signing a patch, I had to configure per-directory\n> with `patatt install-hook`. I have more than a hundred git worktrees\n> (think of dozens of git repositories, and half a dozen worktrees --see\n> git-worktree(1)-- per repository). If I need to configure every one of\n> those worktrees to sign all of my patches, that's going to be\n> cumbersome. Also, I scrape and re-create worktrees for new branches\n> all the time, so I'd need to be installing hooks for patatt(1) all the\n> time. Compare that to having mutt(1) configured once. It doesn't\n> scale that well.\n\nAlso true -- patatt was really envisioned as a library for b4, where you can\nconfigure patch signing in your ~/.gitconfig for all projects.\n\n-K\n"},{"id":"484652","messageId":"20231109180308.GA2711684@coredump.intra.peff.net","threadId":"60484","inReplyTo":"ZUz6H3IqRc1YGPZM@debian","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-11-09T18:03:08Z","receivedAt":"2023-11-09T18:03:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 09, 2023 at 04:26:23PM +0100, Alejandro Colomar wrote:\n\n> I've tried something even simpler:\n> \n> ---8<---\n> #!/bin/sh\n> \n> mutt -H -;\n> --->8---\n> \n> I used it for sending a couple of patches to linux-man@, and it seems to\n> work. I don't have much experience with mutt, so maybe I'm missing some\n> corner cases. Do you expect it to not work for some case? Otherwise,\n> we might have a winner. :)\n\nWow, I don't know how I missed that when I read the manual. That was\nexactly the feature I was thinking that mutt would need. ;)\n\nSo yeah, that is obviously better than the \"postponed\" hackery I showed.\nI notice that \"-H\" even causes mutt to ignore \"-i\" (a sendmail flag that\nGit adds to sendemail.sendmailcmd). So you can just invoke it directly\nfrom your config like:\n\n git config sendemail.sendmailcmd \"mutt -H -\"\n\nAnnoyingly, \"-E\" doesn't work when reading over stdin (I guess mutt\nisn't willing to re-open the tty itself). But if you're happy with not\nediting as they go through, then \"-H\" is then that's enough (in my\nworkflow, I do the final proofread via mutt).\n\n-Peff\n"},{"id":"484678","messageId":"ZU1kgO1SppJdNjvY@debian","threadId":"60484","inReplyTo":"20231109180308.GA2711684@coredump.intra.peff.net","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-09T23:00:16Z","receivedAt":"2023-11-09T23:00:19Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Jeff,\n\nOn Thu, Nov 09, 2023 at 01:03:08PM -0500, Jeff King wrote:\n> On Thu, Nov 09, 2023 at 04:26:23PM +0100, Alejandro Colomar wrote:\n> \n> > I've tried something even simpler:\n> > \n> > ---8<---\n> > #!/bin/sh\n> > \n> > mutt -H -;\n> > --->8---\n> > \n> > I used it for sending a couple of patches to linux-man@, and it seems to\n> > work. I don't have much experience with mutt, so maybe I'm missing some\n> > corner cases. Do you expect it to not work for some case? Otherwise,\n> > we might have a winner. :)\n> \n> Wow, I don't know how I missed that when I read the manual. That was\n> exactly the feature I was thinking that mutt would need. ;)\n> \n> So yeah, that is obviously better than the \"postponed\" hackery I showed.\n> I notice that \"-H\" even causes mutt to ignore \"-i\" (a sendmail flag that\n> Git adds to sendemail.sendmailcmd). So you can just invoke it directly\n> from your config like:\n> \n> git config sendemail.sendmailcmd \"mutt -H -\"\n\nHmm great then! Definitely a winner. :)\n\n> \n> Annoyingly, \"-E\" doesn't work when reading over stdin (I guess mutt\n> isn't willing to re-open the tty itself). But if you're happy with not\n> editing as they go through, then \"-H\" is then that's enough (in my\n> workflow, I do the final proofread via mutt).\n\nSince git-send-email allows editing, I usually edit with that. Having\n-E would be redundant (and in fact it felt like that to me with your\nsuggested mutt-as-mta.sh) for my use case.\n\nCheers,\nAlex\n\n> \n> -Peff\n\n-- \n\n"},{"id":"484685","messageId":"ZU1-l4PwMU5H4_VN@debian","threadId":"60484","inReplyTo":"20231109180308.GA2711684@coredump.intra.peff.net","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-10T00:51:34Z","receivedAt":"2023-11-10T00:51:38Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Jeff,\n\nOn Thu, Nov 09, 2023 at 01:03:08PM -0500, Jeff King wrote:\n> On Thu, Nov 09, 2023 at 04:26:23PM +0100, Alejandro Colomar wrote:\n> \n> > I've tried something even simpler:\n> > \n> > ---8<---\n> > #!/bin/sh\n> > \n> > mutt -H -;\n> > --->8---\n> > \n> > I used it for sending a couple of patches to linux-man@, and it seems to\n> > work. I don't have much experience with mutt, so maybe I'm missing some\n> > corner cases. Do you expect it to not work for some case? Otherwise,\n> > we might have a winner. :)\n> \n> Wow, I don't know how I missed that when I read the manual. That was\n> exactly the feature I was thinking that mutt would need. ;)\n> \n> So yeah, that is obviously better than the \"postponed\" hackery I showed.\n> I notice that \"-H\" even causes mutt to ignore \"-i\" (a sendmail flag that\n> Git adds to sendemail.sendmailcmd). So you can just invoke it directly\n> from your config like:\n> \n> git config sendemail.sendmailcmd \"mutt -H -\"\n\nHaving it directly in sendmailcmd causes some glitch: It repeats all CCs\nin TO. See a log:\n\n\tSend this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y\n\tOK. Log says:\n\tSendmail: mutt -H - -i kevin@8t8.us mutt-dev@mutt.org alx@kernel.org e.sovetkin@gmail.com neomutt-devel@neomutt.org\n\tFrom: Alejandro Colomar \n\tTo: Kevin McCarthy ,\n\t\tmutt-dev@mutt.org\n\tCc: Alejandro Colomar ,\n\t\tJenya Sovetkin ,\n\t\tneomutt-devel@neomutt.org\n\tSubject: [PATCH] send.c: Allow crypto operations in batch and mailx modes.\n\tDate: Fri, 10 Nov 2023 01:41:24 +0100\n\tMessage-ID: <20231110004128.5972-2-alx@kernel.org>\n\tX-Mailer: git-send-email 2.42.0\n\tMIME-Version: 1.0\n\tContent-Transfer-Encoding: 8bit\n\n\tResult: OK\n\nThe sent mail ended up being\n\n\tFrom: Alejandro Colomar \n\tTo: Kevin McCarthy , mutt-dev@mutt.org, alx@kernel.org,\n\t\te.sovetkin@gmail.com, neomutt-devel@neomutt.org\n\tCc: Alejandro Colomar ,\n\t\tJenya Sovetkin , neomutt-devel@neomutt.org\n\nSo maybe we need the wrapper script to ignore the arguments.\n\nCheers,\nAlex\n\n> \n> Annoyingly, \"-E\" doesn't work when reading over stdin (I guess mutt\n> isn't willing to re-open the tty itself). But if you're happy with not\n> editing as they go through, then \"-H\" is then that's enough (in my\n> workflow, I do the final proofread via mutt).\n> \n> -Peff\n\n-- \n\n"},{"id":"484709","messageId":"ZU4widBlHljjg9lL@debian","threadId":"60484","inReplyTo":"ZU1-l4PwMU5H4_VN@debian","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-10T13:30:49Z","receivedAt":"2023-11-10T13:30:52Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"On Fri, Nov 10, 2023 at 01:51:34AM +0100, Alejandro Colomar wrote:\n> Hi Jeff,\n> \n> On Thu, Nov 09, 2023 at 01:03:08PM -0500, Jeff King wrote:\n> > On Thu, Nov 09, 2023 at 04:26:23PM +0100, Alejandro Colomar wrote:\n> > \n> > > I've tried something even simpler:\n> > > \n> > > ---8<---\n> > > #!/bin/sh\n> > > \n> > > mutt -H -;\n> > > --->8---\n> > > \n> > > I used it for sending a couple of patches to linux-man@, and it seems to\n> > > work. I don't have much experience with mutt, so maybe I'm missing some\n> > > corner cases. Do you expect it to not work for some case? Otherwise,\n> > > we might have a winner. :)\n> > \n> > Wow, I don't know how I missed that when I read the manual. That was\n> > exactly the feature I was thinking that mutt would need. ;)\n> > \n> > So yeah, that is obviously better than the \"postponed\" hackery I showed.\n> > I notice that \"-H\" even causes mutt to ignore \"-i\" (a sendmail flag that\n> > Git adds to sendemail.sendmailcmd). So you can just invoke it directly\n> > from your config like:\n> > \n> > git config sendemail.sendmailcmd \"mutt -H -\"\n> \n> Having it directly in sendmailcmd causes some glitch: It repeats all CCs\n> in TO. See a log:\n> \n> \tSend this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y\n> \tOK. Log says:\n> \tSendmail: mutt -H - -i kevin@8t8.us mutt-dev@mutt.org alx@kernel.org e.sovetkin@gmail.com neomutt-devel@neomutt.org\n> \tFrom: Alejandro Colomar \n> \tTo: Kevin McCarthy ,\n> \t\tmutt-dev@mutt.org\n> \tCc: Alejandro Colomar ,\n> \t\tJenya Sovetkin ,\n> \t\tneomutt-devel@neomutt.org\n> \tSubject: [PATCH] send.c: Allow crypto operations in batch and mailx modes.\n> \tDate: Fri, 10 Nov 2023 01:41:24 +0100\n> \tMessage-ID: <20231110004128.5972-2-alx@kernel.org>\n> \tX-Mailer: git-send-email 2.42.0\n> \tMIME-Version: 1.0\n> \tContent-Transfer-Encoding: 8bit\n> \n> \tResult: OK\n> \n> The sent mail ended up being\n> \n> \tFrom: Alejandro Colomar \n> \tTo: Kevin McCarthy , mutt-dev@mutt.org, alx@kernel.org,\n> \t\te.sovetkin@gmail.com, neomutt-devel@neomutt.org\n> \tCc: Alejandro Colomar ,\n> \t\tJenya Sovetkin , neomutt-devel@neomutt.org\n> \n> So maybe we need the wrapper script to ignore the arguments.\n\nHeh! The following trick works as well, without needing a script:\n\n[sendemail]\n\tsendmailcmd = mutt -H - && true\n\nIt probably relies too much on git-send-email(1)'s current\nimplementation, but it works. :)\n\nCheers,\nAlex\n\n> \n> Cheers,\n> Alex\n> \n> > \n> > Annoyingly, \"-E\" doesn't work when reading over stdin (I guess mutt\n> > isn't willing to re-open the tty itself). But if you're happy with not\n> > editing as they go through, then \"-H\" is then that's enough (in my\n> > workflow, I do the final proofread via mutt).\n> > \n> > -Peff\n> \n> -- \n> \n\n\n\n-- \n\n"},{"id":"484712","messageId":"ZU6bRb-BXsQfn4ji@debian","threadId":"60484","inReplyTo":"5yn2w52iymgnobesoi2jdwpyzaf5foc4sytxfdzl4vavlox62j@7att57ya6scz","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2023-11-10T21:06:07Z","receivedAt":"2023-11-10T21:06:16Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Konstantin,\n\nOn Thu, Nov 09, 2023 at 12:59:23PM -0500, Konstantin Ryabitsev wrote:\n> On Thu, Nov 09, 2023 at 06:42:19PM +0100, Alejandro Colomar wrote:\n> > I haven't yet tried b4(1), and considered trying it some time ago, but\n> > really didn't find git-send-email(1) and mutt(1) so difficult to use\n> > that b4(1) would simplify much.\n> \n> Well, sending is only a small part of what b4 will do for you -- the core\n> benefits are really cover letter management, automatic versioning and\n> simplified list trailer collection. It's all tailored to kernel needs, but it\n> will work for any project that depends on mailed patches.\n> \n> > But I have tried patatt(1) before, which is what I think b4(1) uses for\n> > signing. Here are some of my concerns about patatt(4):\n> > \n> > It doesn't sign the mail, but just the patch.\n> \n> Well, no, it signs the entire thing, not just the patch, but it's true that\n> it's specifically targeted at patches (hence the name).\n> \n> > There's not much\n> > difference, if any, in authenticability terms, but there's a big\n> > difference in usability terms:\n> > \n> > To authenticate a given patch submitted to a mailing list, the receiver\n> > needs to also have patatt(1) configured. Otherwise, it looks like a\n> > random message.\n> \n> Yes, but that's a feature.\n> \n> > MUAs normally don't show random headers (patatt(1)\n> > signs by adding the signature header), so unless one is searching for\n> > that header, it will be ignored. This means, if I contribute to other\n> > projects, I need to tell them my patch is signed via patatt(1) in\n> > order for them to verify. If instead, I sign the email as usual with my\n> > MUA, every MUA will recognize the signature by default and show it to\n> > the reader.\n> \n> I go into this in the FAQ for patatt:\n> https://github.com/mricon/patatt#why-not-simply-pgp-sign-all-patches\n> \n> Basically, developers really hated getting patches signed with PGP, either\n> inline or MIME, which is why it never took off. Putting it into the header\n> where it's not seen except by specialized tooling was a design choice.\n\nIt would be interesting if MUAs would support PGP signatures in a\nheader. Did you consider that option back then? Maybe patching a\nmutt(1) or neomutt(1) to do that would have been simpler than developing\npatatt(1).\n\n> \n> > It also doesn't allow encrypting mail, so let's say I send some patch\n> > fixing a security vulnerability, I'll need a custom tool to send it. If\n> > instead, I use mutt(1) to send it signed+encrypted to a mailing list\n> > that provides a PGP public key, I can reuse my usual tools.\n> \n> Right, the goal was really *just* attestation. For encrypted patch exchange we\n> have remail (https://korg.docs.kernel.org/remail.html), which worked\n> significantly better than any other alternative we've considered.\n> \n> > Also, and I don't know if b4(1) handles this automagically, but AFAIR,\n> > patatt(1) didn't: fo signing a patch, I had to configure per-directory\n> > with `patatt install-hook`. I have more than a hundred git worktrees\n> > (think of dozens of git repositories, and half a dozen worktrees --see\n> > git-worktree(1)-- per repository). If I need to configure every one of\n> > those worktrees to sign all of my patches, that's going to be\n> > cumbersome. Also, I scrape and re-create worktrees for new branches\n> > all the time, so I'd need to be installing hooks for patatt(1) all the\n> > time. Compare that to having mutt(1) configured once. It doesn't\n> > scale that well.\n> \n> Also true -- patatt was really envisioned as a library for b4, where you can\n> configure patch signing in your ~/.gitconfig for all projects.\n\nOverall, I think mutt(1) works better for me than patatt(1) via b4(1)\nfor crypto operations. I don't use software that doesn't work with\nPGP/MIME, and it's more versatile. I'm still curious about the other\nfeatures of b4(1), so I'll try it for those.\n\nThanks!\nAlex\n\n> \n> -K\n\n-- \n\n"},{"id":"484713","messageId":"20231110214104.GA2758295@coredump.intra.peff.net","threadId":"60484","inReplyTo":"ZU4widBlHljjg9lL@debian","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-11-10T21:41:04Z","receivedAt":"2023-11-10T21:41:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 10, 2023 at 02:30:49PM +0100, Alejandro Colomar wrote:\n\n> > Having it directly in sendmailcmd causes some glitch: It repeats all CCs\n> > in TO. See a log:\n\nAh, right. That makes sense. send-email has to pass all of the envelope\nrecipients on the command-line, which mutt then interprets as\ndestinations to add to \"to\". Mutt is smart enough to de-duplicate the\n\"to\", but it (correctly) allows duplicate to/cc. (My basic test didn't\nhave any cc's).\n\n> > So maybe we need the wrapper script to ignore the arguments.\n> \n> Heh! The following trick works as well, without needing a script:\n> \n> [sendemail]\n> \tsendmailcmd = mutt -H - && true\n> \n> It probably relies too much on git-send-email(1)'s current\n> implementation, but it works. :)\n\nI was going to suggest the same thing. And no, I don't think it is\nrelying on any send-email implementation details. Git always tries to\nfeed command-invoking config like this to the shell for consistency (and\nto allow tricks like this).\n\n-Peff\n"},{"id":"484727","messageId":"xmqqh6ltuqvq.fsf@gitster.g","threadId":"60484","inReplyTo":"ZU4widBlHljjg9lL@debian","subject":"Re: git-send-email: Send with mutt(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-11-10T23:31:53Z","receivedAt":"2023-11-10T23:31:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alejandro Colomar writes:\n\n> [sendemail]\n> \tsendmailcmd = mutt -H - && true\n\nAh, this is fun, an ugly but serviceable trick to ignore the command\nline arguments. I briefly wondered it would work equally well and\nmuch more readable to simply append \"#\", but the above should work\njust fine.\n"}]}