Jeff King <peff@xxxxxxxx> wrote: > 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). Yeah, it would be limited to git send-email users, only :< > > 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. nzb (an XML format) seems to be the thing for Usenet binaries, nowadays. Maybe it's workable for git, maybe it's overkill or not worth it for the two (non-.onion) NNTP servers we have. nzb seems widely supported enough (on a Debian jessie system): $ apt-cache search nzb sabnzbdplus - web-based binary newsgrabber with nzb support sabnzbdplus-theme-classic - classic interface templates for the SABnzbd+ binary newsgrabber sabnzbdplus-theme-iphone - transitional package for migration to sabnzbdplus-theme-mobile sabnzbdplus-theme-mobile - mobile interface templates for the SABnzbd+ binary newsgrabber sabnzbdplus-theme-plush - plush interface templates for the SABnzbd+ binary newsgrabber sabnzbdplus-theme-smpl - smpl interface templates for the SABnzbd+ binary newsgrabber libnzb-dev - An nzb based Usenet binary grabber (development files) libnzb0c2a - An nzb based Usenet binary grabber (runtime library) lottanzb - simple and automated Usenet downloader for Newzbin (NZB) files nzb - Usenet binary grabber nzbget - command-line based binary newsgrabber for nzb files python-pynzb - unified API for parsing NZB files from NNTP (Usenet) servers spotweb - web interface to search and filter Usenet spots -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html