On 02/13/2017 09:37 AM, Johannes Schindelin wrote:
Hi Arif,
On Mon, 13 Feb 2017, Arif Khokar wrote:
Thanks for the link. One thing that comes to mind that is that it may
be better to just download the patches and then manually apply them
afterwords rather than doing it in the script itself. Or at least add
an option to the script to not automatically invoke git am.
I actually had expected *you* to put in a little bit of an effort, too. In
fact, I was very disappointed that you did not even look into porting that
script to use public-inbox instead of GMane.
I wasn't aware of that expectation. My idea was to use NNTP as a way to
facilitate the development of a new git utility that would serve as the
inverse of git-send-email (sort of like the relationship between git
format-patch and git am), rather than using a
IIRC, I had posted some proof-of-concept Perl code to do so back in
August in
<DM5PR17MB1353B99EBD5F4FD23360DD41D3ED0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Looking at public-inbox now at the archives of this group, it appears
that several of the messages I sent weren't archived for some reason
(and I didn't see any more responses to what I posted at the time). The
messages are accessible via NNTP when connecting to gmane though.
Also, looking at the source of the message I referenced, it appears that
my MUA decided to base64 encode the message for some reason (which may
have resulted in it getting filtered by those who I sent the message to).
I will look into this more now (given yours and Junio's responses).
Getting back to the point I made when this thread was still active, 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. That would make it easier
compared to the different, ad-hoc, methods that exist for each email
client.
You can always do that yourself: you can modify your cover letter to
include that information.
Certainly, but it would be nice to be able to have it done automatically
by git format-patch (which I'll look into).
Note that doing this automatically in format-patch may not be appropriate,
as 1) the Message-ID could be modified depending on the mail client used
to send the mails
I think the best approach would be not to make including the message-id
values the default behavior. Specifying a new command-line option to
enable that behavior should address those concerns I think.
and 2) it is not unheard of that a developer
finds a bug in the middle of sending a patch series, fixes that bug, and
regenerates the remainder of the patch series, completely rewriting those
Message-IDs.
Perhaps, but should something like that not warrant a re-roll of sorts.
That is, one should reply to the partial patch series stating that there
is a bug that renders this particular patch (series) un-usable and the
re-roll could be posted as a reply to the original cover letter?
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.
At this point, I am a little disinterested in a discussion without code. I
brought some code to the table, after all.
If you have the time, please take a look at the message-id I referenced.
If you need, I can re-post the proof-of-concept code.