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:
> > > > 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.