Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Wed, Aug 24, 2016 at 06:49:38PM +0000, Eric Wong wrote:

quoted

quoted

Given that public-inbox provides an NNTP interface, couldn't the ARTICLE
<message-id> NNTP command be used to easily retrieve the messages in a
given patch series (at least compared to POP or IMAP).  Perhaps
git-send-email could be modified to include the message-id value of each
patch in the series that it sends to the mailing list and include it in
the cover letter.

I think that makes sense; perhaps an X-Git-Followups: header
from send-email which lists the child Message-IDs the same way
References: does for ancestors.  (perhaps there's already a
standardized header for listing children)

I think that's harder to adapt to some workflows, since it implies
generating all of the message-ids ahead of time (whereas if you are
feeding the messages into an existing MUA, it may generate them on the
fly as it sends).

I thought about allowing a giant MIME message with all the
patches attached, too but that won't work for a large patch
series due to size limits along various SMTP hops.
Compression might make spam filters unhappy, too.

This was a problem faced by binary groups on Usenet, which had to split
large files across many messages.

It has been a long time since I've dealt with those, but I think the
state of the art involved using "1/20", "2/20", etc in the subjects to
piece together the original. There may also have been header or body
content that included a unique id, so you always knew which messages
were part of a set.

They also used things like forward error correction to handle dropped
messages, but I don't think we need to go that far.

So parsing the "PATCH 1/20" headers sounds hacky, but I think it has
worked for years in other communities.

-Peff