From: Jeff King Date: Wed, 24 Aug 2016 19:12:38 GMT Subject: Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path] Message-ID: <20160824191238.taeodwd2hz7q55gv@sigill.intra.peff.net> In-Reply-To: <20160824184938.GB8578@whir> 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 > > > 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