[PATCH libgpg-error] doc: clarify patch submission workflow
tmz at pobox.com
Sun Feb 4 05:55:11 CET 2018
[Apologies for the relative length of this reply. Brevity
is not my strong suite. ;)]
Daniel Kahn Gillmor wrote:
> On Thu 2018-02-01 15:55:48 -0500, Todd Zullinger wrote:
>> I have my doubts that git send-email will ever directly
>> support PGP/MIME. But if signed patches are desired,
>> there's no reason not use git format-patch to generate a
>> patch (whether a single patch or a series with a cover
>> letter) and then use any decent mail client to send the
> you're suggesting a mail client that can take an existing file that
> contains an RFC822-formatted message, and will let the user sign and
> send it without this kind of stuff:
>> Using git send-email is generally just convenient for folks
>> whose mail clients would otherwise mangle the whitespace,
>> wrap the text, or otherwise bugger the patch content.
> i'd like to know which mail clients you use that really make that
> workflow easy :)
Mutt doesn't do too badly here. Receiving a PGP/MIME signed
patch can be easily decoded and saved, then applied using
git am. It's only a matter of using decode-copy versus copy
when saving the patch(es) (or using $pipe_decode for someone
piping a patch directly from mutt to git am).
That said, my main point is that I don't think it is likely
that git send-email will support PGP/MIME natively soon, if
ever¹. And as such, I think describing a workflow that is
not possible in the HACKING file isn't the most friendly
thing (essentially what Damien said).
It seems better to me to either leave out the ", preferably
PGP/MIME signed" bit or describe a workflow for someone
reading the HACKING file that can reasonably be followed.
What that workflow is depends a bit on how the GnuPG
maintainers incorporate patches from the list, which I don't
> PGP/MIME will preserve the whitespace. Inline PGP signatures are a
> whole other kettle of (messed up) fish, and should not be attempted.
Teaching most mail clients to save a message without the
PGP/MIME is probably trickier than with mutt, but I imagine
maintainers and users who have a git workflow based on email
use mail clients where this is feasible.
If GnuPG wants to use signed patches, that's certainly
great. It may be easier to do so using a slightly different
workflow, depending on how difficult it is for new
contributors to generate PGP/MIME formatted messages from
Attaching messages and then signing them may be easier. Of
course, some mail clients won't show the patches "attached"
inline, but some mail clients just suck more than others. :)
Another option might be to recommend that users generate
patches with git format-patch² and then process them using
another script which can PGP/MIME sign them. That script
could either send the signed patches directly or feed them
to git send-email (as far as I know, git send-email won't
have trouble with already signed messages, but I haven't
I don't know if there's already a convenient script to
create PGP/MIME messages or not. It would be handy to have
in many situations, I imagine, and very well may already
exist. If so, it should be relatively easy to suggest to
users whose mail clients don't make this as easy as mutt
(or, I presume gnus).
¹ If someone wants git send-email to support PGP/MIME
signing, they would need to propose patches to git. It
would likely need to be done using either Perl or C (and
rewriting git send-email in C first) to incur no
significant new requirements in git.
I say simply this based on my following of the git
community over the years (and partly as a distro packager
of git who would prefer that a core tool like git
send-email avoids growing many more dependencies).
² Recommending git format-patch and then git send-email is
better in any case, IMO. Junio has stated a few times on
the git list that allowing git send-email to drive git
format-patch seems like a bad decision. Most recently,
Money can't buy happiness, but it sure makes living in misery easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 543 bytes
Desc: not available
More information about the Gnupg-devel