Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

Johannes Schindelin [off-list ref] writes:

The problem is not Perl, but how fiddly it is to set up. And that you lose
all the niceties of an email client (e.g. when you want to add a comment
before the diff stat that is not intended to become a part of the commit
message).

Just this part.  I do not think that is fair to send-email.  You are
blaming its "feature" that allows it to drive format-patch, which I
do not consider is the proper part of the command and to which I
kept saying from the early days of its introduction that I'd never
use it and I think we should discourage its use exactly because it
encourages a bad workflow (i.e. you skip the final proof-reading
before sending out, and you cannot add footnote comments).

Treat it like an MSA just like Thunderbird, just designed to be more
suited to send out patches without corruption, and you will be OK.
You work, commit and write your message with your favourite editor,
do format-patch, reword or add footnote with your favourite editor,
and then send it out.  You can avoid letting other MSAs that may
corrupt whitespaces touch what you will send out if you used
send-email, but that is not mandatory.  As long as your favourite
MSA does not corrupt your message, you can use it.

Somebody mentioned "configuring it is hard--why does the user have
to know SMTP subtleties", and that may be a valid complaint against
the primary part of send-email.  The solution for that is not to
discard it with bathwater, but make it just as easy as other MSAs,
say, Thunderbird, to configure for an average user who can configure
these other MUAs.

Junio C Hamano [off-list ref] wrote:

Somebody mentioned "configuring it is hard--why does the user have
to know SMTP subtleties", and that may be a valid complaint against
the primary part of send-email.  The solution for that is not to
discard it with bathwater, but make it just as easy as other MSAs,
say, Thunderbird, to configure for an average user who can configure
these other MUAs.

Sadly, the average user does not use an MUA, SMTP or IMAP, anymore.
It's all webmail or apps using proprietary protocols.
Embrace, extend, extinguish :<

Hi,

On Sat, 6 Aug 2016, Eric Wong wrote:

Junio C Hamano [off-list ref] wrote:

quoted

Somebody mentioned "configuring it is hard--why does the user have
to know SMTP subtleties", and that may be a valid complaint against
the primary part of send-email.  The solution for that is not to
discard it with bathwater, but make it just as easy as other MSAs,
say, Thunderbird, to configure for an average user who can configure
these other MUAs.

Sadly, the average user does not use an MUA, SMTP or IMAP, anymore.
It's all webmail or apps using proprietary protocols.
Embrace, extend, extinguish :<

I think you both got it wrong. The original citizens were the mail clients
that allowed you to communicate with other human beings. Webmail is just a
new generation of the same commodity. It is our usage to transport
machine-readable content (and not as an attachment!) that is the intruder.

It's not making things better if we require users to use a second mail
client for sending out patches, and, oh, it does nothing to help with
reintegrating patches back into Git, were they had been before taking that
perilous and lossy journey through that medium called email.

Ciao,
Dscho