I’m generating my own artisanal message-id’s, thank you.

https://paste.centos.org/view/d7c0ef61

@brauner It's for neomutt -- this is my my_hdr setting.

@monsieuricon I hope you quote the result.

tr -d 'A-Za-z0-9' < /usr/share/dict/words | sort | uniq -c

isn’t empty.

Also, I find one 45-character entry there, so three of them will end up with a line that is much longer than the “SHOULD not be more than 78 characters” line length.

Not that anybody should care about that crazy legacy limit, but still..

@torvalds You're right, it's really only there in case diceware isn't found, though.

In all honesty, the random words are just a quirk I came up with while being bored on a call and it should really just be:

echo "$(date +%Y%m%d)-$(openssl rand -hex 12)@whatevs"

@brauner no, looks like there's no option to override it at all other than via calling the send-hook and setting my_hdr.

Updated script that is probably saner when diceware isn't installed.

https://gist.github.com/mricon/b1ef6e10cceb227352274e1b888409b0

@monsieuricon @brauner Cool! Now if only we could replace the hard-coded logic in `git send-email` with this...

@brauner @gregkh @monsieuricon Aye, the b4 ones are rather nice. Certainly nicer than what you get out of git send-email, or god forbid, gmail.

@brauner @monsieuricon I should at least try b4 out for new development. As @horms points out here:
https://lore.kernel.org/r/ZCU4BQ0C4K6HoBsf@corigine.com
I need all the luck I can get with my current "journey of a few hundred patches" that I'm on, and my current git branch / commit / rebase / rebase / rebase / rewrite / rebase / format-patch / send-email workflow leaves a lot to be desired at times.

@brauner @gregkh Yes, it's based off the change-id of the series, though it also makes sense to change it to be the latest date. Feel free to suggest this on the tools list.

@nathanchance @gregkh @brauner @horms @monsieuricon "you can embed the recipients of the series/patch into the cover letter once" to be fair, you can do this using git alone.
Been putting off using b4 for sending, I kinda wanna see what someone's workflow looks like before switching.

@nathanchance @brauner @horms @gregkh @monsieuricon I was talking about branch descriptions, and format-patch's --cover-from-description argument. I don't doubt that b4 is easier though.

@nathanchance with current b4 master, you can just "b4 prep --show-info series-range"

@brauner @monsieuricon Nice! I'm stealing that right now...

@brauner @monsieuricon I was wondering about that...

Got the message id to work in mutt, will add it to git send-email tomorrow.

@brauner @monsieuricon Your git-hook doesn't seem to work for me as 'git format-patch' does not generate the message-id, git send-email does (when it is sending the message). Are you generating a message-id before you run 'git send-email' somehow?

@brauner @monsieuricon ah, maybe you are using --thread on 'git format-patch'? That might get messy as the message ids are now not correct (you rewrote them), and --thread doesn't work on single patches

@brauner @monsieuricon Ok, you are forcing me to switch to use b4 for my development workflow now, fair enough :)

In the meantime, let me just send this bugfix patch out and stop messing around with pretty message-ids as the bugfix is probably more important in the short-term...

@brauner @monsieuricon Ok, I lied, I couldn't resist doing it "by hand" to see if it would work, and it did: https://lore.kernel.org/lkml/2023040126-blandness-duckling-bd55@gregkh/

@brauner @monsieuricon Much better. But not quite there, the script now strips out the "@" character and trailing text from the message id for some reason.

"2023040117-gem-unharmed-3194@gregkh" gets turned into "Message-Id: <2023040117-gem-unharmed-3194>"

But nice work with the inline perl, I have to use it for that reason alone!

@dakkar @monsieuricon @brauner Debugging a embedded perl script in a bash script for git run to use to send email for a Linux kernel patch over a social media message is yak shaving at it's finest.

Unfortunately, no, this change did not work, let me go dig up my old perl book from the upstairs library...

@dakkar @monsieuricon @brauner yup, that worked, many thanks!

@brauner @monsieuricon @dakkar Thanks!

In the never-ending series of things that really don’t matter but are fun, something is still not working. I just tried sending a patch out with this and the gmail server did not like it at all, and rewrote the message id with:

  Message-ID: <64293fdb.5d0a0220.58d3f.02e0SMTPIN_ADDED_BROKEN@mx.google.com>
X-Google-Original-Message-ID: <2023040245-stardust-obtain-0b4d@gregkh> usage.

Ah, in typing that out I see why, the original email header was:

Subject: [PATCH] MIPS: vpe-cmp: remove module owner pointer from struct class
 usage.

So the perl script changed that to:

Subject: [PATCH] MIPS: vpe-cmp: remove module owner pointer from struct class
Message-Id: <2023040245-stardust-obtain-0b4d@gregkh>
 usage.

And then vger promptly ate the message and never delivered it to the mailing list. I’ll hand-edit the subject line to be one line for now to get stuff done, but be aware of this if you use it as-is.

@brauner @gregkh @dakkar you've entered a room consisting of many corners. You are likely to be eaten by a Grue. :)

@brauner @monsieuricon @dakkar better, thanks!

But (you knew there was a but)…

message ids no longer have <> characters: `Message-Id: 2023040228-pastor-evidence-1269@gregkh Is that intentional and still a valid message id? As @monsieuricon said, email parsing is rough.

@gregkh @brauner @dakkar angle brackets are not optional for message-IDs, so they really should be in there.

@monsieuricon @brauner @dakkar Ah, so the python email library messed up again? Heck, if we are allowed to write full scripts here (and not just bash one-liners), let me try something on my own, worst case I write it in C...

@brauner @monsieuricon @dakkar Ah, makes sense.

Anyway, rewrote it in perl as that way I have a chance to maintain it over time: https://paste.sr.ht/~gregkh/d8cd98966d8e5ef61161c0341b250d018b16e8bd

@gregkh @brauner @dakkar @monsieuricon what, maintain over time in the write once, read never language?

@vbabka @brauner @dakkar @monsieuricon Yes, it's better than the "write once, and then rewrite again, and again, and again as the language updates itself and breaks previously-working scripts over the years" :)

@brauner @dakkar @monsieuricon
Ok, all now working properly, and bonus, the message-id is now part of the signature on the email itself!