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

Jeff King [off-list ref] wrote:

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

quoted

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

Yeah, it would be limited to git send-email users, only :<

quoted

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