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

[Arif Khokar <arif.i.khokar@gmail.com>]

On 02/13/2017 02:21 PM, Junio C Hamano wrote:
> Arif Khokar <arif.i.khokar@gmail.com> writes:
>
>> ... I
>> still think it would be better to be able to list the message-id
>> values in the header or body of the cover letter message of a patch
>> series (preferably the former) in order to facilitate downloading the
>> patches via NNTP from gmane or public-inbox.org.
>
> You are looking at builtin/log.c::make_cover_letter()?  Patches
> welcome, but I think you'd need a bit of preparatory refactoring
> to allow gen_message_id() be called for all messages _before_ this
> function is called, as currently we generate them as we emit each
> patch.

Thank you for the advice; I'll look into it.

One concern I have regarding this idea is whether or not SMTP servers 
typically replace a Message-Id header set by the client.  If that's the 
case, then this approach may unexpectedly fail for some people depending 
on what email provider they use (if they don't maintain their own MTA 
setup).

>> Alternatively, or perhaps in addition to the list of message-ids, a
>> list of URLs to public-inbox.org or gmane messages could also be
>> provided for those who prefer to download patches via HTTP.
>
> Many people around here do not want to repeat the mistake of relying
> too much on one provider.  Listing Message-IDs may be a good idea,
> listing URLs that are tied to one provider is less so.

I agree.  I've actually thought that it would be useful to mirror a 
read-only copy of the mailing list on a public newsgroup that could be 
accessed through a free provider such as eternal-september.org or the 
Google groups interface.  It certainly would reduce the potential losing 
easy access to the archives of this email list if gmane and 
public-inbox.org fail.  But I suspect doing something like that would 
potentially increase the spam volume substantially for regular 
participants/contributors.