From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS27357 104.130.224.0/20 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by dcvr.yhbt.net (Postfix) with SMTP id C7E591F6C1 for ; Wed, 24 Aug 2016 19:12:41 +0000 (UTC) Received: (qmail 19250 invoked by uid 109); 24 Aug 2016 19:12:41 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.84) with SMTP; Wed, 24 Aug 2016 19:12:41 +0000 Received: (qmail 6179 invoked by uid 111); 24 Aug 2016 19:12:45 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) by peff.net (qpsmtpd/0.84) with SMTP; Wed, 24 Aug 2016 15:12:45 -0400 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Wed, 24 Aug 2016 15:12:38 -0400 Date: Wed, 24 Aug 2016 15:12:38 -0400 From: Jeff King To: Eric Wong Cc: Johannes Schindelin , Arif Khokar , Jakub =?utf-8?B?TmFyxJlic2tp?= , Stefan Beller , meta@public-inbox.org, git@vger.kernel.org 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> References: <20160819150340.725bejnps6474u2e@sigill.intra.peff.net> <46a5b9b6-f3f6-7650-8a5b-b0b52223e375@gmail.com> <20160824184938.GB8578@whir> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160824184938.GB8578@whir> List-Id: 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