[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git-send-email

From: Kévin Le Gouguec
Subject: Re: git-send-email
Date: Mon, 15 Jun 2020 17:38:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

> You need to look at this from the right vantage point: the POV of me
> (or someone else) who needs to install changes in such an email.  I'm
> on the receiving end of the email, so I have no idea what command(s)
> were used to create and send it.  All I see is a random email message,
> not unlike many others, just with diffs in its body.  You suggest to
> pipe it into Git, but how do I know it's in a proper format to be
> processed correctly by Git?  There's no clue.

Thank you for taking the time to spell out how messages produced by
git-send-email can be challenging to distinguish from handcrafted

Indeed, I agree that it's not uncommon for contributors to send emails
with "[PATCH]" in the subject and the diff appended at the end; it would
be unreasonable to ask maintainers to be able to guess how the message
was produced just by eyeballing it.

Likewise, it would be unreasonable to ask maintainers to pipe random
messages to git-am to find out if they have been produced by
git-send-email; when I said:

> - for maintainers, no need to scan the mail for attachments; just pipe
>   the mail itself to git am.

I really meant "*when maintainers know the mail has been produced by
git-send-email*, there is no need to scan it for attachments; just pipe
it straight to git-am".

FWIW, git-send-email adds a pretty explicit header[1] to inform
recipients of how the message was produced.

> Do you see now why we prefer the latter?  And it isn't like Emacs is
> the only project; many GNU projects also prefer to have patches
> submitted in this format.

I'm certainly not as well-versed in email mishaps as GNU maintainers, so
I'll trust you when you say that attachments fare better than message
bodies vs. the many transit/encoding problems you've listed.  OTOH I
also see that projects working with git-send-email seem to be none worse
for the wear[2].

[1] X-Mailer: git-send-email [VERSION]

[2] Save for some the occasional "some mail service forbids arbitrary
    header fields" shenanigans:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]