Proposal: Remembering message IDs sent with git send-email

I want to gather some thoughts about this. Say you've written a patch series and are getting ready to send a -v2. If you set --in-reply-to=ask, it'll show you a list of emails you've recently sent, and their subject lines, and ask you to pick one to use the message ID from. It'll set the In-Reply-To header to your selection.

I'd also like to add a custom header, X-Patch-Supersedes: <message ID>, with a similar behavior & purpose.

Thoughts?

On Wed, May 08, 2019 at 07:10:13PM -0400, Drew DeVault wrote:

It sounds to me like you mean to call this during `git format-patch` - that is, `git format-patch -v2 --cover-letter --in-reply-to=ask master..branch -o branch/`. That should set the In-Reply-To: header on your cover letter.

There's also the possibility that you mean `git send-email --in-reply-to=ask branch/v2*` - in which case I imagine the In-Reply-To: is added as the message is sent, but not added to the cover letter text file.

Is the hope to store the message ID you choose from --in-reply-to=ask into the X-Patch-Supersedes: header? I'm not sure I understand what you're trying to solve; if you use `git format-patch --in-reply-to` it sounds like the X-Patch-Supersedes: and In-Reply-To: would be redundant.

Is it possible you mean you want (sorry for pseudocode scribblings) [PATCH v2 1/1]->X-Patch-Supersedes = [PATCH 1/1]->Message-Id ? I think that wouldn't look good in a threaded mail client?

Or maybe I totally misunderstood :)

What I think might be useful (and what I was hoping you were going to talk about when I saw the subject line) would be if the Message-Id is conveniently stored during `git send-email` on v1 and somehow saved in a useful place in order to apply to the In-Reply-To field on v2 automatically upon `git format-patch -v2`. I'll admit I didn't know about --in-reply-to=ask and that helps with the pain point I've experienced sending out v2 before.

 - Emily

On 2019-05-08  5:19 PM, Emily Shaffer wrote:

--in-reply-to=ask doesn't exist, that's what I'm looking to add. This convenient storage mechanism is exactly what I'm talking about. Sorry for the confusion.

On Thu, May 09, 2019 at 12:50:25PM -0400, Drew DeVault wrote:

Looking at the documentation, I suppose I hadn't realized before that --thread will generate a Message-Id for your cover letter. It does seem like we could teach --thread to check for the previous patch's cover letter in the directory provided by -o. Of course, this wouldn't work if the author was generating v2 and didn't have the v1 files available (i.e. different workstation or different author picking up the set).

I'm still not sure I see the value of the extra header proposed here. I'd appreciate an explanation of how you think it would be used, Drew.

I don't know much about emailed workflows outside of Git; is this something likely to be useful to other communities?

 - Emily

On 2019-05-09 11:51 AM, Emily Shaffer wrote:

I'm not just thinking about your run of the mill mail reader, but also mail readers which are aware of git and could use it to provide git-specific features for browsing patchsets. Distinguishing it from the mecahnism used for normal conversation allows us to have fewer heuristics in such software.

Drew DeVault <sir@cmpwn.com> wrote:

Using Net::NNTP to query NNTP servers using ->xover([recent-ish range]) to scan for Message-IDs and Subjects matching the current ident could be an option, too.

It could cache the xover result for --dry-run and format-patch cases; and Net::NNTP is a standard Perl module. Going online to do this query also benefits people who work across different machines/environments, as it's one less thing to sync.

Fwiw, this list has:
	nntp://news.gmane.org/gmane.comp.version-control.git
	nntp://news.public-inbox.org/inbox.comp.version-control.git

And there's a bunch of kernel lists at nntp://nntp.lore.kernel.org/